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The  COMRADE  Data  Management  System  (CDMS)  is  a generalized  data 
base  management  system  that  has  been  developed  as  an  independently 
useful  part  of  the  Computer-Aided  Design  Environment  (COMRADE) 

System.  CDMS  consists  of  two  distinct  components:  a set  of  host 
language  subroutines  which  enable  CDMS  functions  to  be  embedded 
within  FORTRAN  Extended  and  COBOL  application  programs;  and  a set 
of  conversational  programs  which  enable  a user  seated  at  a key- 
Q*-  display  terminal  to  define.  1 
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query  a CDMS  data  base,  to  issue  a variety  of  file  management 
commands,  and  to  access  a number  of  auxiliary  capabilities.  This 
report  provides  an  overview  of  CDMS,  and  describes  the  procedural 
steps  involved  in  the  use  of  the  CDMS  conversational  interface. 
CDMS  operates  on  the  DTNSRDC  Control  Data  6700  computer. 
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FORF.WORD 


The  comprehens i ve  Computer-Auied  Dosiqn  Environment 
(COMRADE)  software  system  has  been  developed  at  the  David  W. 
Taylor  Naval  Shxp  Research  and  Development  Center  and  sponsored 
by  the  Naval  Sea  Systems  Command  (NAVSEA,  formerly  NAVSHIPS)  in 
support  of  their  Computer-Aided  Ship  Design  and  Construction 
(CASDAC)  effort  to  facilitate  the  design  and  construction  of 
Naval  vehicles.  Although  conceived  in  support  of  ship  design, 
the  COMRADE  software  has  been  developed  for  use  as  a general 
design  tool.  Three  separate  components  are  included:  the 
COMRADE  Executive  System;  the  COMRADE  Data  Management  System; 
and  the  COMRADE  Design  Administration  System.  All  of  these 
components  are  operable  on  the  DTNSRDC  Control  Data  6700  com- 
puting system  (SCOPE  3.4  operating  system)  and  are  documented 
in  a set  of  eight  DTNSRDC  reports: 

COMRADE  - The  Computer  Aided  Design  Environment  Project, 
An  Introduction 

COMRADE  Executive  System  Users  Manual 

COMRADE  Data  Storage  Facility  Users  Manual 

COMRADE  Absolute  Subroutine  Utility  Users  Manual 

COMRADE  Data  Management  System  Primer 

COMRADE  Data  Management  System  Host  Language  Interface 
Users  Manual 

COMRADE  Data  Management  System  Conversational  Interface 
Users  Manual 

COMRADE  Design  Administration  System  Users  Manual 
Inquiries  concerning  any  of  the  components  of  the  COMRADE 
system  should  be  directed  to  the  Computer  Systems  Development 
Group,  Computer  Sciences  Division,  DTNSRDC. 

It  is  understood  and  agreed  that  the  U.S.  Government  shall 
not  be  liable  for  any  loss  or  damage  incurred  from  the  use  of 
these  computer  programs. 


V 


TAHLl-.  Oi’  CONTENTS 


Page 


I,  INTRODUCTION  TO  TllK  COMRADE  DATA  MANAGEMENT 

SYSTEM 1 

A.  SYSTEM  CLASSIFICATION  AND  ORIENTATION 1 

B.  TRI -LEVEL  ARCHITECTURE 4 

C.  BASIC  CONCEPTS  AND  TERMINOLOGY 5 

D.  SYSTEM  FEATURES  AND  CAPABILITIES 12 

E.  DATA  BASE  ADMINISTRATION 20 

F.  POSSIBLE  COURSE  OF  FURTHER  SYSTEM  DEVELOPMENT..  21 

II.  OVERVIEW  OF  THE  CDMS  CONVERSATIONAL  INTERFACE 23 

A.  ROLE  OF  THE  INTERFACE 2 3 

B.  FILE  MANAGEMENT 2 3 

C.  DATA  BASE  DEFINITION 24 

D.  DATA  BASE  LOADING  AND  DUMPING 24 

E.  DATA  BASE  UPDATING 2 5 

F.  OUERY  PROCESSING 26 

G.  DATA  BASE  STATISTICS 26 

H.  AUXILIARY  FACILITIES 26 

III.  DETAILED  DESCRIPTION  OF  THE  CONVERSATIONAL 

INTERFACE 27 

A.  ENTERING  ANU  EXl  TING  CDMS 27 

B.  USE  OF  GLOBAL  COMMANDS 28 

1.  FILE  MANAGEMENT  COMMANDS 28 

ATTACH 28 

CATALOG 2 9 

PURGE 29 

UNLOAD 29 

DATABASE 30 

COPYDB 30 

FILES 3 0 

2.  AUXILIARY  C(  MMANDS 31 

EDITOR 31 

OUTPUT 31 

SEND 32 

HELP 32 

EXIT 32 

3.  MODULE  EXECUTION  COMMANDS 3 2 

C.  USE  OF  PROGRAM  MODULES 3 3 

1.  The  DEFINE  Medule 3 3 

2.  The  LOAD  Module 37 

3.  The  UPDATE  Module 47 

4.  The  QUERY  Module 51 

5.  The  STATS  Module 60 

6.  The  DUMP  Module 63 

ACKNOWLEDGMENTS 7 2 


vi  i 


FKECLUlNa  PAUS  BUNUMOT  ni>i£U 


Page 


APPKNDIX  A 
APPENDIX  B 
APPENDIX  C 
APPENDIX  D 
APPENDIX  E 
PEFEHENCES 


Figure  1 - 
Figure  2 - 


- COMRADE  PERMANENT  FILE  MANAGEMENT  SYSTEM....  73 


- DTNSRDC  CHARACTER  SET 77 

- SAMPLE  TERMINAL  SESSION  USING  CDMS 79 

- SUMMARY  OF  CDMS  STORAGE  CAPACITIES 87 

- USE  OF  CDMS  IN  BATCH  ENVIRONMENT 89 


91 


LIST  OF  FIGURES 


Page 

DTNSRDC  Control  Data  6700  Computing  Facility..  3 

Data  Base  Definition  and  Processing  Using 

CDMS 6 


V i i i 


A 


INTRODUCTION  TO  TUH  COMKADR  DATA  MANAGKMRNT  SYSTEM 


I . 

A.  SYSTEM  CLASSIRICATION  AND  ORIENTATION 

Generalized  data  base  management  systems  might  be 
classified  as  either  self-contained  or  host  language  interface 
types.  A self-contained  system  typically  provides  all  essential 
capabilities  for  data  definition,  data  maintenance,  data  re- 
trieval, and  report  formatting.  In  addition,  a self-contained 
system  usually  provides  a generalized  retrieval  language  that 
can  be  used  to  express  fairly  complex  selection  criteria. 

In  contrast,  a host  language  system  provides  (1)  a capability 
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high-level  calls,  which  may  be  embedded  in  application  programs 
written  in  procedure  languages  such  as  FORTRAN  or  COBOL.  It 
is  via  specialized  application  programs  that  the  end  user 
of  a host  language  data  base  performs  data  maintenance,  query 
processing,  and  report  formatting  procedures.  Although  a host 
language  system  always  provides  an  application  program  inter- 
face to  the  data  base,  such  an  interface  may  also  be  included 
in  a self-contained  system  as  has  been  done  by  the  data 
management  component  of  the  Computer-Aided  Design  Environment 
(COMRADE)  System. 

The  Computer  Aided  Design  Environment  (COMRADE)  system 
developed  at  the  David  W.  Taylor  Naval  Ship  Research  and 
Development  Center  (DTNSRDC)  in  support  of  the  Computer-Aided 
Ship  Design  and  Construction  (CASDAC)  Project  provides  a self- 
contained  type  of  data  base  management  system  which  includes 
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the  conversational  interface  described  in  the  payes  that 
follow.  This  system,  called  the  COMRADE  Data  Manayemcnt 
System  (CDMS)  is  designed  to  enable  non-computer  personnel 
to  define,  load,  update,  and  query  a data  base.  Moreover, 

It  supports  a host  language  interface  to  FORTRAN,  CODOL,  and 
COMPASS  assembly  language  programs,  so  that  when  specialized 
needs  arise--as  frequently  happens  with  CASDAC  application 
software,  for  exampio--appl icat ion  programs  can  be  developed 
to  interact  as  necessary  with  the  data  base.  The  host  language 
interface  is  therefore  an  important  component  of  CDMS. 

CDMS  was  developed  in  the  FORTRAN  Extended  programming 
language,  and  is  intended  primarily  for  use  in  scientific 
applications.  It  was  designed  to  facilitate  management  of 
numeric  information  used  in  applications  involving  the  design 
and  construction  of  ships,  aircraft,  buildings,  dams,  and 
bridges,  among  others.  Although  CDMS  do'es  provide  for  the 
use  of  textual  values,  it  does  not  facilitate  query  and  main- 
tenance of  textual  data  as  would  bo  required  for  bibliographic 
and  legal  applications. 

CDMS  is  operational  under  the  SCOPE  3.4  operating  system^ 
on  the  DTNSRDC  Control  Data  6700  computing  facility  (Figure  1) 
CDMS  was  developed  by,  and  is  maintained  and  enhanced  by,  the 
Computer  Systems  Development  Group,  Computet  Sciences  Division 
DTNSRDC. 

r 

References  are  listed  on  page  91  in  the  order  of  their  use. 
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Figure  1 - ITI^ISRDC  Control  Data  670CI  Conputing  Facility 
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^'DMS  IS  hierarchically  structured  into  three  levels.  Users 
are  permitted  access  to  their  data  at  any  of  the  throe  levels. 
The  flexibility  provided  by  such  a desiqn  permits  the  individual 
user  to  maxe  his  own  trade-offs  between  ease  of  use  of  tfie 
system  and  compu ta t i ona 1 efficiency. 

The  lowest  level  CDMS  component,  the  COMRADE  Data  Storaqe 
2 

Facility  (CDSF),  supports  storaqe,  retrieval,  modification, 
and  deletion  of  named  va r iab le- 1 enq t h loqical  records  or  data 
.blocks,  and  the  optional  buildinq  and  processinq  of  inverted 
data  lists  for  retrieval  of  information  based  on  data  values. 

The  subroutines  of  CDSF  are  generally  used  by  the  system  pro- 
grammer who  values  economy  of  computer  time  and  space  above  all 
else.  CDSF  constitutes  the  foundation  for  higher-level  CDMS 
components . 

The  next  higher  level  CDMS  component  comprises  a set  of 
host  language  subroutines  which  serve  as  the  interface  between 
an  application  program's  data  requirements  and  CDSF.  It  is  at 
tnis  level  that  logical  items  of  information  and  groups  of 
information  may  be  retrieved  and  updated  by  name.  Information 
may  also  be  retrieved  by  way  of  queries  involving  keyed  data 
attributes.  Variable-length  logical  records  may  be  defined 
as  groupings  of  s i ng 1 e-va 1 ued  elements,  arrays,  and  repeating 
groups  of  elements.  Pointer-type  elements  may  be  used  to  link 
records  into  a variety  of  logical  data  structures. 
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The  third,  and  highest,  level  CDMS  component  is  provided  to 
make  the  system  most  usable  to  non-computer-oriented  personnel. 
This  component  comprises  a set  of  modules  suitable  for  use  in 
batch  mode  but  designed  primarily  for  conversational  use.  In 
the  conversational  mode,  a user  seated  at  a keyboard/printer 
or  display  terminal  may  define,  load,  update,  and  interrogate 
his  data  base.  As  with  the  host  language  interface,  the  con- 
versational interface  allows  a user  to  work  with  logical  items 
of  information.  While  performing  data  base  retrieval,  a user 
specifies  his  selection  criteria  in  English-like  phrases.  All 
of  the  CDMS  conversational  commands  are  available  to  any  valid 
user  of  DTNSRDC's  INTERCOM  time-sharing  system.^ 

The  performance  of  data  base  definition  and  processing  at 
the  three  levels  of  CDMS  are  depicted  in  Figure  2. 

C.  BASIC  CONCEPTS  AND  TERMINOLOGY 

. DATA  BLOCK.  The  basic  unit  of  data  storage  within  a CDMS 
data  base  is  the  data  block.  Each  data  block  is  assigned  a 
unique  name  of  as  many  as  eight  characters,  the  first  of  which 
must  be  a letter,  which  is  used  in  all  retrieval  and  update 
transactions  involving  information  in  that  block;  thus  for 
example,  in  a data  base  of  information  about  U.S.  Presidents, 
data  pertaining  to  John  F.  Kennedy  might  conceivably  be  collected 
into  a data  block  given  the  name  KENNEDY;  similarly,  within  a 
ship  design  file,  information  about  a particular  deck  would 
likely  be  grouped  intr-  a data  block  given  a name  such  as  DK03. 
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BLOCK  TYPE.  A CDMS  data  base  file  cowprisas  one  or 


more  sets  of  data  blocks.  Lach  set  has  a unique  record  format 
or  definition  called  a "block  type"  description.  This  de- 
scription gives  tne  logical  structure  of  all  data  blocks  of 
that  particular  block  type.  The  description  defines  subblocks, 
repeating  groups,  and  dat^  elements  and  defines  the  data  type 
(i.e.,  single  or  multi-valued,  alphanumeric,  pointer,  real  and 
integer)  and  inversion  status  of  each  element.  A U.S. 

Presidents  data  base,  for  example,  might  have  38  data  blocks 
of  the  block  type  PKLS  (personal  information  about  the  Presi- 
dents) and  48  data  blocks  of  the  block  type  ELECTION  (informa- 
tion pertaining  to  presidential  elections). 

To  further  illustrate  the  block  type  concept,  assume  that 
the  personnel  department  of  a large  installation  has  a data 
base  containing  personal  data  on  each  of  the  installation's 
employees.  Personal  data  tor  an  employee  named  Tom  Jones  might 
be  stored  in  a data  block  named  JONES,  and  personal  data  for  an 
employee  named  John  Smith  stored  'n  a data  block  named  SMITH. 
Although  this  data  base  may  include  many  data  blocks,  all  blocks 
storing  personal  data  will  be  of  the  same  block  type  perhaps 
named  EMPLOYEE.  The  block-type  description  for  the  EMPLOYEE 
blocks  indicates  the  kinds  of  data  values  contained  in  that 
set  of  data  blocks.  The  description  may  for  instance,  indicate 
that  the  third  data  value  in  the  data  blocks  JONES,  SMITH, 
etc.,  is  the  integer  value  for  the  data  element  AGE,  and  that 
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tne  fifth  data  value  in  each  of  these  data  blocks  is  the 


a 1 phanumer 1 c value  for  the  element  BIRTHDAY. 

. SUBBLOCK . E-'or  convenience  in  ocyanizinq  and  retrieving 
data  elements,  a data  block  can  be  subdivided  into  uniquely 
named  groups  of  data  elements  known  as  subblocks.  Subblocks 
may  be  used  to  group  logically  related  elements  and  to  provide 
access  to  subsets  of  data  values  within  a data  block. 

Each  data  block  may  contain  as  many  as  eight  subblocks.  A 
subblock  name  may  be  as  many  as  eight  alphanumeric  characters 
long,  the  first  always  a letter. 

. DATA  ELEMENT.  In  CDMS,  the  data  element  is  the  smallest 
unit  of  data  that  can  be  defined  and  referred  to  by  name  (the 
name  to  be  as  many  as  eight  characters  long,  with  the  first  a 
letter).  There  are  three  classes  of  data  elements  --  numeric, 
alphanumeric  and  pointer: 

(a)  A numeric  data  element  may  contain  either  teal  or 
integer  values,  and  may  be  either  a s ing 1 e-va 1 ued 
quantity  (represented  by  a single  60-bit  CDC  6000 
computer  word)  or  a var  iable-length  array  of  sue): 
values.  If  an  array  of  values  is  given,  the  data 
element  name  will  refer  to  all  of  the  values  in  the 
array.  The  CDMS  host  language  subroutines  do,  how- 
ever, provide  a means  of  referring  to  a particular 
array  element  if  its  position  within  the  array  is 
prov  ided . 
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(b)  An  alphanumeric  data  element  may  be  either  a sinqle 


value  (made  up  of  as  many  as  ten  CDC  60U0  display 
code  characters),  an  array  of  such  values,  or  a 
var iable-lenqth  text  strinq. 

(c)  Pointer  data  elements  are  used  to  construct  a data 
structure  (tree,  ring,  network)  that  links  all 
related  data  blocks.  A pointer  element  in  one  data 
blocK  may  "point"  to  a different  data  block  on  the 
same  data  base  file,  or  it  may  "point"  to  a data 
block  stored  on  a different  data  base  file  entirely. 

A pointer  data  element  may  be  defined  either  as  a 
single  value  or  an  array  of  values. 

. REPEATING  GROUP.  Iv'ithin  a data  block,  one  to  50  con- 
secutively-defined data  elements  of  the  same  or  different 
type  may  be  grouped  together  and  defined  as  a repeating  group. 

A repeating  group  is  identified  by  a name  (as  many  as  eight 
characters,  beginning  with  a letter)  which  may  be  used  when 
referring  to  the  entire  grouping  of  data  elements.  Each  element 
in  the  group  may,  of  course,  be  referenced  by  its  own  individual 
name . 

A data  block  may  contain  a variable  number  of  repetitions 
or  occurrences  of  repeating  group  values.  Although  there  may 
be  at  most  50  data  elements  in  a repeating  group,  the  number  of 
occurrences  of  values  for  these  elements  is  virtually  limitless. 

To  illustrate  the  repeating  group  concept,  assume  that 
employee  Tom  Jones  has  three  children  and  employee  John  Smith 
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has  but  one  child.  If  in  a block  type  named  EMPLOYEE  there 
exists  a repeating  group  named  CHILDREN,  and  if  CHILDREN  in- 
cludes the  data  elements  NAME  and  AGE,  then  in  the  data  block 


named  JONES  there  would  be  three  occurrences  of  CHILDREN 
(i.e.,  NAME  and  AGE)  while  in  the  data  block  named  SMITH  there 
would  be  only  one  occurrence, 

. INVERTED  DATA  ELEMENT.  Quick  resolution  of  conditional 
retrieval  requests  or  "queries"  issued  from  either  conversa- 
tional terminals  or  application  programs  is  an  important  aspect 
of  data  base  processing.  CDMS  uses  a set  of  "inverted  lists" 
to  minimize  query  response  times.  An  inverted  list  is  a direc- 
tory which  (1)  contains  the  data  values  for  a particular  data 
element  which  was  assigned  inversion  status  when  it  was  defined, 
and  (2)  contains  the  names  of  all  data  blocks  having  values 
for  the  inverted  elements.  The  data-value/block-name  pairs 
are  sorted  by  value. 

To  illustrate,  assume  a CDMS  data  base  of  personnel  data. 
Assume  also  that  the  data  base  contains  data  blocks  of  the  names 
JONES,  SMITH,  JOHNSON,  BROWN,  and  WILSON,  which  contain  personal 
data  on  Tom  Jones,  John  Smith,  Jim  Johnson,  Ed  Brown,  and  Bob 
Wilson,  respectively.  If,  in  the  block  type  EMPLOYEE  there  is 
a data  element  AGE  which  has  been  assigned  inversion  status, 
values  for  the  element  AGE  will  be  stored  in  an  inverted  list 
which  might  look  as  follows: 
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AGE 


SMITH 

JOHNSON 

BROWN 

JONES 

WILSON 


25 

28 

28 

36 

38 


If  the  user  requested  a printout  of  the  values  for  the  data 
element  WEIGHT  (another  data  element  within  EMPLOYEE)  for  all 
persons  at  least  30  years  of  age,  the  inverted  list  for  AGE 
would  be  examined  and  only  those  data  blocks  satisfying  the 
condition  - namely,  JONES  and  WILSON  - selected  for  further 
processing  to  obtain  WEIGHT  information. 

. LOCALLY  DEFINED  DATA  ELEMENTS.  An  individual  data  block 
may  include  data  elements  not  logically  related  to  other  blocks 
of  the  same  block  type.  These  locally  defined  data  elements 
ate  managed  in  exactly  the  same  way  as  the  other  data  elements 
defined  within  a block-type  description  except  that  they  are 
not  considered  for  membership  within  repeating  groups. 

. CROSS  FILE  REFERENCE  TABLE.  In  addition  to  containing 
user-defined  data  blocks,  block  types  and  inverted  lists,  a 
CDMS  data  base  file  contains  a cross-file  reference  table 
which  lists  the  permanent  file  names  of  all  data  base  files 
"pointed  to"  by  pointer  data  elements  contained  within  this 
particular  file.  The  permanent  files  listed  in  the  table 
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may  be  one  of  two  types:  a SCOPt;  permanent  file,  indicated 
by  a f our-character  ID  and  a file  name  of  as  many  as  40 
characters,  or  a CPFMS  (COMRADE  Permanent  File  Management 
System)  file,  inoicated  by  level-three  and  level-four  names. 

(See  Appendix  A for  a detailed  description  of  the  CPFMS  file 
management  capability.) 

D.  SYSTEM  FEATURES  AND  CAPABILITIES 

To  facilitate  the  comparison  of  CDMS  features  with  those 
of  other  generalized  data  base  management  systems,  the  follow- 
ing analysis  has  been  patternea  after  that  of  the  CODASYL 
Technical  Report  of  May  1971^  and  of  the  National  Bureau  of 
Standards  Technical  Note  887  of  November  1975  (a  comparison 
of  SIX  generalized  data  base  management  systems).^  Features 
are  described  under  eight  major  headings:  computer  environ- 
ment, data  structure,  data  definition,  data  maintenance,  query 
specification,  output  and  report  generation,  security  features, 
and  external  linkages.  Each  heading  is  further  subdivided  as 
necessary  to  provide  greater  detail. 

1.  Computer  Environment 

CDMS  is  operational  on  the  DTNSRDC  Control  Data  6700 
computing  facility  which  is  supported  by  the  SCOPE  3.4  operating 
system.  The  core  requirement  for  the  conversational  interface 
approximates  25K  (decimal)  words.  The  core  requirement,  ex- 
cluding buffer  space,  for  the  host  language  interface  and  the 
COMRADE  Data  Storage  Facility  (when  used  with  the  COMRADE 
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Absolute  Subroutine  Utility)  approximates  8K  (decimal)  words. 
The  source  language  for  most  of  CDMS  is  FORTRAN  Extended; 
only  a very  small  number  of  COMPASS  assembly  language  state- 
ments have  been  included. 

The  communication  link  between  the  terminal  user  and  CDMS 
is  supported  by  the  INTERCOM  time-sharing  system.  CDMS  is 
not  coded  re-entrantly . Its  components  may  be  used  in  either 
the  batch  or  the  conversational  mode. 

2.  Data  Structures 

• Data  Types 

CDMS  provides  a set  of  valid  data  types  which  can  be 
defined  for  s ing le-va 1 ued  and  array  elements.  These  valid 
types  are  numeric,  including  real  and  integer  values;  alpha- 
numeric, including  a single  value  of  as  many  as  ten  characters, 
an  array  of  such  values,  and  a variable-length  text  string; 
and  pointer.  A character  may  be  any  letter,  digit,  or  special 
symbol  supported  by  the  hardware  (see  Appendix  B). 

, Logical  Data  Structure 

The  logical  data  structure  is  defined  as  the  com- 
position of  data  elements  in  the  data  blocks,  and  the  inter- 
relationships between  data  blocks  and  their  files  as  deter- 
mined by  the  user  without  regard  for  main  memory  or  secondary 
storage.  CDMS  data  blocks  may  contain  single-valued  and 
variable-length  array  elements.  Var iable-length  repeating 
groups  are  also  permitted.  Data  may  be  interrelated  across 
files  and  among  data  blocks  through  the  use  of  "pointers". 
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thereby  providing  full  network  structuring.  Moreover , inverted 


list  structures  arc  supported  for  s ing Ic-vj 1 ucd  elements. 

, Physical  Storage  Structure 

Data  records  within  CDMS  are  randomly  organized, 
and  are  located  by  transforming  the  data  block  name  into  the 
disK  address.  This  type  of  transformation,  or  hashing  tecfi- 
nique,  makes  it  possible  to  access  a block  during  its  residence 
on  a CDMS  file  by  its  symbolic  name  rather  than  through  a 
nume r ica 1 i ndex  . 

3 . Data  Definition 

CDMS  provides  the  user  with  a block-type  or  data 
definition  language.  This  language  serves  as  the  mechanism 
tor  defining  data  elements,  repeating  groups,  subblocks,  and 
keyed  or  inverted  elements.  The  language  is  card  oriented  - 
one  card  image  for  each  item  to  be  defined.  Within  a card 
image,  fields  may  be  specified  free-form  with  commas  separating 
the  fields. 

4.  Data  Maintenance 

• Data  Base  Loading  and  Input  Analysis 

After  the  user  has  described  his  block-types  to  CDMS, 
the  system  uses  these  descriptions  to  construct  internal  block- 
type  tables,  one  for  each  description.  At  data  base  load  time, 
a block-type  table  is  identified  by  name,  after  which  one  or 
more  data  blocks  of  this  particular  block  .ype  may  be  created 
and,  optionally,  loaded  with  values.  After  a data  block  has 
been  created,  a value  that  is  to  be  loaded  into  that  block  must 
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first  bo  read  from  a soquontially  orqanizod  card  imaqo  file. 

If  the  value  is  numeric,  it  will  be  converted  into  the  proper 
internal  format  pursuant  to  the  data  element  definition 
stored  within  the  block-type  table.  After  conversion,  the 
value  IS  loaded  into  the  data  block  and  referred  to  in  future 
retrieval  and  update  requests  simply  by  its  data  element  name. 
A data  definition  links  the  card  imaqe  file  of  values  to  a 
particular  set  of  block  types. 

• Data  Base  Rest r uc tu r i nq 

The  r es t r uc t u r i nq  of  a data  base  generally  involves 
the  modification  of  the  block  type,  such  as  by  adding  or 
deleting  a data  element  or  repeating  group  definition.  With- 
in CDbS,  data  base  restructuring  is  permitted  so  long  as  no 
data  blocks  have  been  created  foi  a given  block  type.  Re- 
structuring following  creation  of  data  blocks  involves  dumping 
tne  existing  contents  of  those  blocks,  redefining  the  block 
type,  and  re-loading  the  dumped  values.  A utility  program 
IS  available  under  CDMS  for  dumping  the  contents  of  a data 
base . 

• Data  Updates 

Updating  is  the  process  of  adding,  modifying  or 
deleting  the  contents  of  some  part  of  a data  base.  Updating 
differs  from  data  loading  in  that  the  load  process  is  typically 
a batch  procedure  involving  a sizable  quantity  of  values  and 
the  creation  of  new  data  blocks,  whereas  the  update  process 
is  typically  a conversational  procedure  involving  transactions 
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on  exist  inq  data  hlocKs  and  the  use  of  fairly  small  sets  of 


data  values.  In  CDMS,  t.fiete  is  a lanquaqe  for  specifying 
update  1 1 ansact  ions . Tfie  language  differs  from  the  query 
languacje  m tfiat  it  does  not  involve  f.'ng  1 i sh- 1 i ke  phrases 
and  conditional  operations.  The  update  language  does,  how- 
ever, provide  tor  both  the  updating  of  and  the  printing  of 
data  elements.  The  language  is  card  oriented  - one  card 
image  tor  each  update  or  print  operation.  Within  a card 
image,  fields  may  f^c  specified  fcee-form  separated  by  slashes. 

• Other  Maintenance  Capabilities 

Lockout  during  tfie  updating  or  loading  of  a CDMS 
data  base  is  maintained  at  the  file  level.  As  a result, 
only  one  use'r  at  a time  may  modify  a CDMS  data  base  file. 

To  minimize  possible  conflicts  resulting  from  concurrent 
update  or  load  operations,  tfie  scheduling  of  data  base  modi- 
fications may  iiave  to  be  controlled  administratively.  During 
a modification  procedure,  users  may  retrieve  and  print  data 
ijase  values. 

■) . Query  Specification 

• Overall  User-System  Interaction  and  Search 
Spec  if  icat ion 

Query  processing  involves  tfie  selective  retrieval  of 
data  from  a data  fiase.  Witfiin  CDMS,  information  is  entered 
initially  to  identify  the  particular  portion  of  the  data  base 
to  be  interrogated.  That  information  is  followed  by  a set 
of  statements  that  specify  selection  criteria  and  certain 
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actions  to  be  taken,  such  as  print  in  columnar  or  row  format, 
for  example.  The  query  language  is  based  upon  use  of  English- 


like  phrases  which  may  contain  Boolean  combinations  (i.e.,  AND 
or  OR)  of  relational  expressions.  A relational  expression  in 
most  instances  is  a triple  composed  of  a data  element  name, 
a relational  operator  (i.e.,  GT,  GE,  LT,  LE,  NE  or  EQ),  and  one 
data  value;  in  the  case  of  the  operator  "between,"  the  expression 
IS  composed  of  a name,  the  operator  BET,  and  two  values. 

• Multi-File  Searching 

The  CDMS  query  capability  enables  as  many  as  five  data 
base  files  to  oe  searched  initially.  Cross-file  and  intrafile 
pointer  elements  may  be  traversed.  With  the  current  "hit"  file 
(a  "nit"  file  is  a list  of  data  blocks  which  have  satisfied  a 
specific  condition)  as  a starting  point,  as  many  as  eight 
different  pointers  (specified  on  a single  statement)  may  bo 
processed  by  the  system.  Typically,  processing  of  cross-file 
pointers  will  continue  without  user  intervention. 

• Additional  Query  Features 

CDMS  allows  hit  files  to  be  named  and  saved  for  use  in  sub- 
sequent query  statements.  Searches  based  on  values  ot  non- 
inverted  data  elements  may  be  conducted  on  the  data  blocks  named 
in  a hit  file.  A hit  file  name  table,  and  the  number  of  "hits" 
on  a hit  file,  will  be  printed  upon  request. 

A pseudo  batch  mode  is  available  to  the  user  during  con- 
versational query  processing.  In  this  mode,  the  user  may  submit 
a set  of  query  statements  which  will  then  be  checked  for  syntax 
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errors;  if  there  are  no  errors,  the  statements  will  be  executed 
without  further  user  interventions. 

6.  Output  and  Report  Generation 

. Language  Type  and  Media  Selection  Flexibility 

An  output  and  report  generation  capability  is  provided  as 
a subset  of  the  CDMS  Query  capability.  English-like  phrasing 
IS  used  to  specify  one  of  three  report  formats  --  columnar, 
row,  or  simple  list.  Typically,  a report  is  printed  on  the 
user's  keyboard/printer  or  display  terminal.  Lengthy  reports 
can  be  routed  to  off-line  medium  - and  high  speed  printers. 

• Arithmetic  and  Sorting  Capabilities 

Computations  on  retrieved  numeric  vaues  are  supported 

within  CDMS  by  a set  of  built-in  functions  which  include 
sum,  difference,  quotient,  product,  and  columnar  totals, 
and  averages.  Sorting,  also  supported  by  a built-in  function, 
may  be  specified  in  columnar-report  requests  and  may  be 
performed  on  as  many  as  eight  fields  in  accordance  with 
the  order  indicated  (i.e.,  LOW  A,  HIGH  B,  LOW  C,  etc.) 

7.  Security  Features 

• File  Protection  and  Access  Control 

A CDMS  data  base  file  must  be  given  a name  (of  as  many  as 
40  characters),  and  may  be  password  protected  in  accordance  with 
SCOPE  3.4  operating  system  conventions.  The  file  is  protected 
from  unauthorized  access  by  way  of  a set  of  privacy  controls 


18 


specified  at  the  time  tfie  file  is  cataloged  into  the  SCOPL 
system.  Sirice  access  privileges  may  vary  from  user  to  user, 
a variety  of  controls  are  provided  including  read  only,  read 
and  modify,  increase  mass  storage  allocation,  and  delete  a 
file  from  the  SCOPE  file  system. 

An  additional  level  of  CDMS  data  tiase  file  protection  may 
be  imposed  by  way  of  the  COMRADE  Permanent  File  Management 
System  (CPFMS).  A detailed  description  of  the  CPEMS  capability 
is  provided  in  Appendix  A. 

, File  Backup,  Recovery , and  Restart 

At  DTNSRDC,  safeguards  exist  to  prevent  an  on-line  CDMS 
file  from  being  accidentally  destroyed  during  normal  system 
operation  and  normal  loading  of  the  operating  system.  For 
backup  purposes  and  to  guard  against  data  loss  as  a 
result  of  some  of  normal  system  event,  on-line  files  are 
generally  clumped  to  magnetic  tape,  on  a semi-weekly  basis.  A 
variety  of  utility  programs  exist  at  DTNSRDC  for  use  in  more 
frequent  dumping  of  data  base  files.  Among  these  is  the  CDMS 
dump  module,  discussed  in  subsequent  sections  of  this  report. 

8.  External  Linkages 

As  mentioned  previously,  CDMS  supports  a host  language 
interface  to  COBOL,®  FORTRAN  Extended,'^  and  COMPASS^® 
application  programs.  These  programs  request  services  of 
the  host  language  subroutines  through  control  statements 
(such  as  the  CALL  statement  of  FORTRAN  Extended,  for  example). 
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L'.  DATA  BASE  ADMINISTRATION 

In  an  environment  such  as  computer-aided  ship  design,  in 
which  the  data  base  includes  data  to  be  shared  by  many  users 
and  programs,  it  becomes  necessary  for  certain  functions  to 
be  centrally  coordinated  and  controlled.  In  such  an  environment 
the  data  base  must  inevitably  reflect  a compromise  between  the 
needs  of  the  various  competing  users  and  their  programs. 
Conflicts  resulting  from  such  diverse  needs  must  be  satis- 
factorily mediated  and  resolved.  Generally  this  role  of 
arbitrator  is  performed  by  a data  base  administrator  (DBA) 
who  possesses  data  processing  experience,  communications  skills, 
and  a working  familiarity  with  user  operations.  The  DBA  is 
responsible  for  functions  spanning  three  broad  categories  of 
data  base  design  and  management:  organization,  monitoring,  and 
reorganization. 

• 0 rjj_a  n j z_a  t i^  n 

During  the  organization  of  a data  base,  the  DBA  assesses 
the  needs  of  the  competing  users  and  programs.  Following  a 
determination  of  all  the  data  requirements,  the  DBA  will  (a) 
use  the  block-type  definition  language  to  define  the  logical 
structure  of  the  data  base  including  those  subblocks,  repeating 
groups,  and  data  elements  that  serve  to  model  the  problem  with 
which  the  data  base  will  be  concerned;  (b)  coordinate  data  base 
loading  and  updating  activities;  (c)  assign  data  base  file  names 
and  access  controls,  taking  into  account  the  access  ^^rivileges 
of  all  data  base  users;  and  (d)  coordinate  tlie  activities  of 
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specialists  working  to  organize  the  data  base. 


• Mon  1 tor  1 ng . During  the  life  cycle  of  a data  base,  it  is 
the  DBA's  responsibility  to  develop  strategies  for  monitoring 
the  use  of  the  data  base,  breach  of  privacy,  frequency  of 
backup,  and  the  need  for  reorganization. 

• Heo r gan i za  t ion  . As  a result  of  information  obtained  from 

the  monitoring  procedure,  or  because  of  the  changing  data  re- 
quirements of  the  users  and  their  programs,  the  DBA  may  find 
that  the  data  base  must  be  reorganized.  The  DBA  may  (a)  change 
the  olocK-type  aescr  ipt  ions ; (b)  reassign  access  controls; 

(c)  alter  the  frequency  of  backup  operations;  (d)  change  the 
data  base  contents  to  reflect  changes  in  the  dIock  types  and 
tne  logical  data  structure;  and  (e)  remove  from  the  data  base 
any  allocated  storage  space  not  currently  being  used  pro- 
duct ively . 

These  activities  indicate  the  kinds  of  functions  for  which 
the  DBA  and  his  staff  are  responsible.  Since  many  of  the  user 
languages  supported  by  CDMS  are  oriented  towards  non-computer 
personnel,  they  are  most  appropriate  for  use  by  the  DBA  and 
any  persons  working  under  his  direction  in  that  they  allow 
operations  to  be  readily  formulated  and  concisely  stated. 

F.  POSSIBLE  COURSE  OF  FURTHER  SYSTEM  DEVELOPMENT 

As  the  computer-aided  ship  design  systems  of  CASDAC 
progress  from  the  planning  stage  to  the  developmental  stage. 
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augmentation  of  CDMS  will  likely  be  required.  This  effort 
would  be  undertaken  along  two  fronts:  enhancements  of  CDMS 
features  and  capabilities  on  the  DTNSRDC  computing  facility, 
which  is  to  eventually  become  an  operating  node  of  the  Navy 
laboratory  computing  network;  and  development  of  a subset  of 
CDMS  features  and  capabilities  on  a set  of  minicomputers 
which  are  to  be  located  at  the  Naval  Ship  Engineering  Center 
ana  linKed  to  the  DTNSRDC  computer. 
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II.  OVERVIEW  OP  THE  CUMS  CONVERSATIONAL  INTERFACE 

A.  ROLE  OF  THE  INTERFACE 

The  CDMS  con  ve  r sa  t iona  1 interface  serves  to  link  trie 
user --per  haps  a data  base  administrator  (DBA),  an  enqineer, 
or  a non-computer-or  rented  manaijer  seated  at  a keyboard/ 
printet  or  display  te r m i na 1 --w  i th  his  data  base  and  a compre- 
hensive set  of  data  management  tools  that  are  operable  on  the 
DTNSRUC  computer.  Interactive  techniques  enable  the  user  to 
perform  his  data  base  analysis,  and  to  eval uate--apd , if 
necessary,  rectify--the  outcome  immediately,  without  under- 
going the  delay  and  inevitable  interruption  to  his  train  of 
thought  that  is  associated  with  operating  in  the  batch  mode. 

The  conversational  interface  enables  the  user  to  define, 
load,  update,  and  query  a data  base  file.  Moreover,  it  enables 
him  to  generate  certain  types  of  reports;  obtain  statistical 
information  about  data  blocks,  block  types,  and  inverted  lists; 
issue  a variety  of  file  management  commands;  and  access  a 
number  of  auxiliary  capabilities  such  as  the  INTERCOM  EDITOR 
program. 

B.  FILE  MANAGEMENT 

The  CDMS  conversational  interface  comprises  a set  of  six 
program  modules.  To  facilitate  file  management  among  these 
modules--each  module  is  activated  by  way  of  a module  execution 
command--CDMS  supports  a file  management  command  language. 
Employing  this  language  a user  can  manipulate  files  stored 
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within  the  DTNSRDC  SCOPE  3.4  file  system.  Specifically,  ho 
can  (1)  attach  SCOPE  or  CPEMS  (See  Appendix  A)  files,  (2)  cata- 
log files,  (3)  purqe  files,  (4)  unload  files,  (5)  activate 
data  base  files  for  subsequent  processing  by  conversational 
modules,  (6)  copy  data  base  files,  and  (7)  list  the  names  of 
all  local  files  currently  available  for  use. 


C.  DATA  BASE  DEFINITION 

A user  defines,  modifies,  deletes  and  prints  block-type 
descriptions  with  the  CDMS  DEFINE  program  module.  The  user 
of  the  DEFINE  module  need  not  have  extensive  programming 
experience.  However,  he  should  have  a thorough  knowledge  of 
the  data  which  will  be  included  in  the  data  base,  for  he  must 
provide  very  specific  information  about  each  of  the  subblocks, 
repeating  groups,  and  data  elements  for  each  block  type. 

During  block-type  definition,  the  user  must  provide  a 
name  by  which  the  block  type  will  be  referenced  in  subse- 
quent operations. 

D.  DATA  BASE  LOADING  AND  DUMPING 

After  the  user  has  defined  and  named  his  block  type, 

CDMS  uses  the  definition  to  construct  an  internal  block- 
type  table.  When  the  user  decides  to  create  and  load  data 
blocks  for  the  newly  defined  block  type,  he  calls  upon  the 
CDMS  LOAD  module.  After  a data  block  has  been  created  by 
LOAD,  values  to  be  loaded  into  the  block  are  read  from  a 
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sequentially  organized  card  image  file.  After  a value  has 
been  read,  it  is  converted,  if  necessary,  and  inserted  into 
the  data  block.  If  an  inverted  data  element  is  being  loaded, 
that  element's  inverted  list  is  appropriately  modified.  A 
data  definition  serves  to  link  the  card  image  file  containing 
only  data  values  with  those  elements  defined  in  the  block 
type. 

The  inverse  of  the  LOAD  module  is  the  DUMP  module.  The 
DUMP  module  maps  a data  definition  (similar  to  the  one  used 
during  loading)  against  an  existing,  loaded  data  base  file 
and  produces  a sequentially  organized  card  image  file  of  values 
useful  for  the  restructuring  of  the  data  base. 


L.  DATA  BASE  UPDATING 

With  the  passage  of  time,  data  element  values  often  become 
obsolete.  Moreover,  values  not  known  at  LOAD  time  later  become 
available.  Accordingly,  the  UPDATE  module  provides  capabilities 
for  adding,  modifying,  and  deleting  individual  data  element 
values,  and  for  creating  and  deleting  data  blocks.  In  addition, 
the  UPDATE  module  provides  capabilities  for  displaying  the 
values  of  specified  portions  of  the  data  base  (such  as  entire 
data  blocks  or  individual  subblocks,  repeating  groups,  and  data 
elements ) . 
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F.  QUERY  PROCESSING 

Query  piocessinq  is  the  selective  retrieval  of  data  from 
a data  base.  The  CDMS  QUERY  module  searches  inverted  lists 
to  determine  which  data  blocks  satisfy  the  user-imposed 
conditions.  Using  a resultant  set  of  data  blocks  (i.e.,  a 
"hit"  tile)  as  a basis  for  further  processing,  the  user  can 
im.pose  additional  search  criteria,  search  non-inverted  elements, 
print  relevant  information  in  his  choice  of  three  report 
formats,  or  trace  a string  of  pointers  to  its  terminal  point 
(another  set  of  data  blocks). 

G.  DATA  BASE  STATISTICS 

A CDMS  user  may  occasional ly  find  it  helpful  to  have  a 
profile  of  the  contents  of  his  data  base.  The  STATS  module 
displays  statistical  information  about  the  data  blocks,  block 
types,  and  iiivt-iLed  lists  contained  in  the  data  base. 

H.  AUXILIARY  FACILITIES 

A number  of  auxiliary  features,  activated  by  a command 
language,  are  provided  to  assist  the  CDMS  user  with  his 
conversational  operations: 

The  INTERCOM  EDITOR  program 

. A facility  that  causes  a given  report  to  bo  printed  at 
the  user's  terminal  and/or  written  to  a local  file. 

. A capability  which  causes  a local  report  file  to  be 
routed  to  off-line  medium-  and  high-speed  printers. 

. A capability  which  tutors  the  CDMS  conversational  user. 
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III.  DETAILED  DESCRIPTION  OF  THE  CONVERSATIONAL  INTERFACE 


A.  ENTERING  AND  EXITING  CDMS 

Any  valid  user  of  the  DTNSRDC  INTERCOM  time-sharinq  system 

may  gain  access  to  the  CDMS  conversational  interface  simply  by 

entering  the  command  ' .’.'/•.•L' / , 'i.vr.  An  INTERCOM  user  already 

executing  within  the  Computer-Aided  Design  Environment 

(COMitADE)  ^ --perhaps  he  has  been  using  some  of  the  COMRADE 

1 2 

Executive  System's  command  procedures--need  only  enter  the 
acronym  . 

After  CDMS  has  boon  initiated,  the  user  may  issue  certain 
"global"  file  management,  auxiliary,  and  modulo  execution 
commands.  These  commands,  termed  "global"  because  they  do  not 
relate  exclusively  to  a particular  CDMS  modulo,  are  indicated 
in  the  following  list; 

File  Managemiont  A u x 1 1 i a / y Module  Execution 


A TTA  ■ ■// 

K:  I'TOF 

: EFI.’IE 

CATAL'''! 

OUTF’IT 

L:  A! 

V'lHCE 

see: 

QUEEY 

u;u,0AD 

HEl.P 

UEFA TE 

COPYDli 

9 

EXIT 

ST  A TS 

:,A  TA  HA  HE 

DUMP 

FILES 
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A global  command  (such  as  ATTA  "}!,  for  example)  might  be  issued 
after  a user  enters  the  DEPINE  module,  or  after  he  enters  the 
QUERY  module,  or  perhaps  even  before  he  enters  any  of  the  CDMS 
modules.  Upon  completion  of  CDMS  conversational  operations  the 
user  need  only  enter  the  global  command  EXIT.  If  the  user  who 
has  . ed  from  CDMS  wishes  to  leave  COMRADE  but  to  remain 
"logged  in"  to  INTERCOM,  he  should  type  the  command  SIGtrFF. 

The  user  wishing  to  terminate  his  INTERCOM  session  should  type 


B.  USE  OF  GLOBAL  COMMANDS 

1.  File  Management  Commands 

-'I  I ' ‘-r'  lii-t. 

Any  SCOPE  permanent  file  or  CPFMS  file  (see  Appendix  A) 
can  be  rendered  accessible  to  the  various  CDMS  program  modules 
by  issuing  the  ATTA  '//  command.  The  parameter  1‘'k  is  the  local 
file  name.  The  parameter  r fn  is  the  permanent  file  name  if  the 
file  is  a SCOPE  file;  for  a CPFMS  file,  pj'>.  must  consist  of  the 
level- 3 name  followed  by  a comma  and  the  level- 4 name.  The 
parameter  : irami'ter  li:>t  must  include  the  ID  and  any  passwords 
or  permissions  needed  to  grant  access  to  the  SCOPE  file;  for  a 
CPFMS  file,  the  rai-ar’etev  I i r.  t may  consist  of  either  of  the 
optional  parameters  IW  (denoting  pseudo-password)  and  MR=1  (as 
described  on  page  5-12  of  the  SCOPE  Reference  Manual^). 

Examp les : 

ATTACH,  CDMSDB,  PRES  I DENTSDB , ID=COMR. 

ATTACH,  SDF,  DDG3,  DDG3,  MR=1, 
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Ifn,  pf'i,  pnV'i'^.c  t < r> 

Any  SCOPE  or  CPFMS  file  created  when  CUMS  modules  arc- 
beinq  used  may  be  cataloqed  in  the  computer  system.  Th<-  i^.ir  i- 
meters  and  p fn  are  as  described  in  the  'i!  command  (s-’O 

earlier  paragraph).  The  parameter  ; ••  r must  include 

the  , the  ' (account  number)  and  any  passwords  or  permissions 
needed  to  control  access  to  the  SCOPE  file;  for  a CPFMS  file 
t.he  ; ; >•  :":r  • 1 : r t may  consist  of  ei*‘her  of  the  optional 
parameters  :'W  (pseudo-password)  or  FL  (file  access  lock;  consult 
the  discussion  presented  in  Appendix  A). 

/ ;r,  ' . 

A SCOPE  or  CPFMS  file  can  be  removed  as  a catalocied  f j 1- 
LJSG  of  thio  ' ^ coirjni^nd.  TMc?  tor’s  ’**  , * » 

and  ; irame  r.;r  llci  are  as  described  for  the  commian  : . 

Note  that  a CPFMS  file  ran  be  purged  only  if  it  has  not  been 
attached,  and  that  unlike  the  purge  of  a SCOPE  tile,  a CPFMS 
file  will  be  unloaded  after  it  has  been  purged. 

If  a SCOPE  file  has  been  attached  with  the  corr'.  ct  pi  r- 
missions,  the  parameters  pfr.  and  pavirieter  L ' : may  be  omitted 
from  the  PURCF  command.  For  further  discussion  see  pages  5-14 
and  5-15  of  the  SCOPE  Reference  Manual^. 

FSLOAl'  Ifr.lirt 

The  ''fJi.'-'A:  command  allows  a user  to  unload  one  or  more 
SCOPE  or  CPFMS  files.  The  parameter  ij'nli.'t  may  consist  of  one 
or  more  local  file  names  separated  by  commas. 
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Kx.im:  It'S; 

r\LOAD,  CDMSDH,  PRESDB,  SDF. 
or 

ENLi'AD,  CUMSDB. 

I'NLOAD,  PRESDB. 

UNLOAD,  SDF. 


Th>'  Lf  command  allows  the  user  to  declare  a parti- 

cular tile  as  the  "active"  data  base.  The  data  base  to  be 
sfiecified  may  be  either  a permanent  file  which  has  been  attached, 
a newly  created  data  base,  or  a data  base  which  the  user  is 
about  to  creatf'.  All  CDMS  program  modules  will  operate  on  the 
"active"  data  base  until  another  rATABA'.'E  command  is  issued. 

For  all  m.odules  except  the  QUERY  module,  the  parameter 
must  consist  of  only  one  local  file  name;  when  used  with  the 
QUERY  module,  the  parameter  may  consist  of  up  to  five 

local  file  names. 

: Y !•  ! ;'k 

The  ' ; Y:  !i  command  allows  the  user  to  copy  and  compress 
the  "active"  data  base  file  (i.e.,  the  file  referred  to  in  the 
most  recent  . .’-TABAUF  command)  . The  parameter  I fn  is  the  name 
of  the  file  which  is  the  result  of  the  copy  and  compression 
process . 

file:; 

The  FILE::  command  allows  the  user  to  obtain  a print  out 
of  the  names  of  all  the  local  files  which  are  available  for 
processing;  permanent  files  will  be  identified  with  an 
aster  isl<  ( * ) . 
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Auxiliary  Commands 


During  the  course  of  execution,  certain  of  the  CDM.S 

program  modules  (DEFINE,  LOAD,  DUMP)  require  that  "injiut  Liles" 

be  submitted  by  the  user.  The  C command  allows  tlie  user 

to  enter  the  INTERCOM  EDITOR  program  to  create  the  necessary 

files  and/or  to  modify  files  created  previously.  (See  the  CDC 

4 

INTERCOM  Reference  Manual  6000,  Version  4,  Chapter  11-2.  ) 

Plans  are  underway  to  enable  the  user  to  enter  EDITOR 
directly  from  any  module  of  CDMS  by  simply  typing  in  the  command 
When  he  leaves  the  EDITOR  program,  he  will  tlie;,  l.<- 
returned  to  the  module  from  which  he  onter'al.  iiowever,  ; -r  t 'o- 

present,  the  following  tirocedure  must  bo  follow  -d.  The  user 

types  in  the  command  /'/  and  receives  a messane  tollin’:  i;  im. 

that  he  is  about  to  leave  CDMS.  Next,  he  is  put  in  the  li.'TERCO.M 
"command"  mode  and  he  must  then  again  tyu'c  It;  t'ni'  eur.uT.and 
He  may  then  perform  any  necessary  procossincj  wittiin  EDll'OR, 
leaving  the  normal  manner  (via  the  EDITOR  command  or 

Once  again  in  the  "command"  mode,  the  user  must  tyt>e  ’ ■ 

to  return  to  the  program  modulo  he  was  executing  when  he  first 
typed  h: : r ;. 

, .'it- 

The  'J?I 'y  command  allows  the  user  to  specify  wlietiu'r 
his  output  IS  to  be  printed  at  his  terminal,  written  off-line 
onto  a "Report  File",  or  written  to  both  destinations.  The 
parameter  must  be  one  of  the  following:  (denoting 
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tlic  user's  terminal);  LF  (denoting  the  "Report  File");  or 
P .'■/  (denoting  both  destinations).  If  no  O’JTP'' command  is 
submitted  during  a CDMS  session,  all  output  will  be  printed  at 
the  user's  terminal. 

• • . • • j • ♦ 

The  .■‘■■VP  command  allows  the  user  to  have  his  "Report 
File"  printed.  The  "Report  File"  migat  contain  output  from 
several  of  the  CDMS  program  modules.  The  parameter  p.ite  must 
be  one  of  the  following;  ^'700  (denoting  building  17,  DTNSRDC); 

(denoting  building  192,  DTNSRDC);  SEC  (indicating  the  1700 
computer,  NAVSEC)  ; or  HEPF.  (denoting  the  user's  terminal). 

The  SELF  command  allows  the  user  in  distress  to  receive 
instruction  on  use  of  the  various  CDMS  commands. 

Exi  ;■ 

The  EX '7  coimiiand  teiininaLes  execution  of  CDMS  coiiversa- 
tional  operations.  Before  the  user  terminates  CDMS,  he  is 
given  the  opportunity  to  ''ATA:  G any  file  created  during  the 
session  and  to  SF.'ID  the  "Report  File"  to  be  printed.  Note  that 
the  EXIT  command  is  not  to  be  used  to  leave  one  CDMS  program 
module  and  enter  another.  To  enter  a different  program  module 
the  user  need  merely  type  in  the  name  of  that  module. 

3.  Module  Execution  Commands 

To  enter  a CDMS  program  module  initially,  or  to  switch 
from  one  module  to  another,  the  user  need  merely  type  in  the 
name  of  the  module  he  desires.  Module  names  are  as  follows: 
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I'h'F  I UK 


LOAF 
:ir:  A I'K 
[IKRY 

K't . H 1 

rijMF 

Detailed  descriptions  of  each  of  these  program  modules  are 
provided  in  the  next  section. 

C.  USE  OF  PROGRAM  MODULES 

1.  The  DEFINE  Module 

The  DEFINE  module  allows  the  user  to  print,  delete, 
create  and  modify  block-type  definitions  on  the  "active"  data 
base  (i.e.,  the  data  base  referred  to  in  the  most  recent 
'ATABADF.  command).  This  data  base  may  be  either  an  existing 
CDMS  data  base  or  one  that  the  user  is  currently  initiating. 

Commands  of  the  DEFINE  Module 

The  four  commands,  i'KlYjT,  DELETE,  CREATE,  and  y.ODTFY, 
supported  by  the  DEI’INE  module  are  as  follows: 

PRINT  l.Lnamf: 

The  PRINT  command  causes  the  block-type  definition  named 
I.tname  to  be  printed.  The  command  PRINT  ALL  causes  all  block 
types  on  the  data  base  to  bo  printed. 


L 
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I F LET E I tKO'Ke 


The  L'ELETE  command  causes  the  block-type  definition  named 
• K.^.”:c  to  be  deleted.  The  command  LELETE  ALL  causes  all  block 
types  on  the  data  base  to  be  deleted. 

'LEA  TF  : ' ' J'*: 

The  'EEATE  command  causes  the  block-type  definition  named 
:.K,2"-.e  to  be  created  and  stored  on  the  data  base.  The  parameter 
' j'k  is  the  name  of  the  local  file  that  contains  the  set  of 
block- type  definition  statements. 

” ; " y } ■ K J :'k 

The  command  causes  the  block-type  definition  named 

' to  be  replaced  by  the  block-type  definition  stored  on 

the  file  ’fn. 

Block-Type  Definition  Statements 

A block-type  definition,  required  as  input  to  the  CREATE 
and  yj'DIEY  commands,  may  consist  of  the  following  three  types 
of  statements.  Note  that  the  CB  statement  for  each  subblock  to 
be  defined  must  be  followed  by  the  entire  set  of  EL  statements 
for  that  subblock,  which  in  turn  must  be  followed  by  the  entire 
set  of  • ; statements  for  that  subblock. 

SR- 11  u / n a n <? 

The  SB  statement  denotes  the  beginning  of  a subblock 
definition;  the  parameter  r,u}>y.arne  must  be  a valid  subblock  name. 

EL-elname,  ti/pfjjpcc 

The  EL  statement  is  used  to  define  a data  element.  The 
parameter  i-lname  must  be  a valid  data  element  name;  the 
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parameter  tyveopec  must  be  one  of  the  following  codes  that 
indicate  the  data  type  of  an  element: 


Alphanumeric 

P,  V 

Inverted  pointer 

T 

Integer 

A A 

Alphanumeric  array 

R 

Rea  1 

I A 

Integer  array 

r 

Pointer 

FA 

Real  array 

A , V 

I nverted 

alphanumeric 

PA 

Pointer  array 

■ i 

Inverted 

integer 

7 

Text 

h\  V 

Inverted 

real 

R r jna^ti 

, c 1 name  1 

e Iname 2 

The  R'] 

statement 

is  used  to 

define  a 

repeating  group.  The 

parameter  ryname  must  be  a valid  repeating  group  name.  The 
parameters  elnamel  and  elna^e'Z  identify  the  data  elements  that 
constitute  the  bounds  of  the  repeating  group's  membership.  If 
the  membership  consists  of  only  one  element,  the  form  of  the 
statement  must  be  hG - rgnane , elname  where  clname  is  the  data 
element  name. 
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Block-Type  Definition,  an  Example 

A user  wishing  to  define  a set  of  blocks  which  are  to 
contain  personal  iniormation  about  each  of  the  U.S.  presidents 
might  specify  the  following  block  type: 


SB-PERSONAL 
EL-SURNAME, A, V 
EL-FIRSTNAM, A 
EL-INITIAL, A 
EL-MONTHB,A 
EL- DAY B, I 
EL-YEARB, I ,V 
EL-STATEB,A,V 
EL-STATEPTR, P 
EL-HEIGHT, A 
EL- PARTY, A, V 
EL-COLLEGE, A 
EL-ANCESTRY , A, V 
EL-RELIGION , A, V 
EL-OCCUP , AA 
EL-MONTHD,A 
EL-DAYD, I 
EL-YEARD, I 
EL-CAUSE, A 

RG- NAME, SURNAME- INITIAL 

RG-BIRTH ,MONTHB-STATEB 

RG-DEATH ,MONTHD-CAUSE 

SB- FAMILY 

EL- FATHER, A 

EL-MOTHER, A 

EL- WIFE, A 

EL-MONTHM,A 

EL-DAYM, I 

EL-YEARM, I 

EL-CHILDREN, I 

RG-MARRI AGE, WIFE-CHILDREN 

SB-HISTORY 

EL-ELECTION, PA 

EL-ADMIN, PA 

EL-CONGRESS , PA 
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2.  The  LOAD  Module 


The  LOAD  module  allows  the  user  to  create  data  blocks 


and  load  them  with  values  taken  from  a card  image  data  file  (Dl’) 
according  to  the  format  indicated  by  a data  definition  (DD) . 

The  LOAD  module  provides  the  following  features: 

The  user  can  save  DD's.  A saved  DD  can  be  used  at  a 
later  time  to  load  another  set  of  data  blocks  and/or  dump 
a set  of  blocks  (see  the  description  of  the  DUMP  module 
for  a discussion  of  the  data  base  dump  process).  A saved 
DD  can  be  printed  on  request. 

. The  names  of  the  data  blocks  to  be  created  can  bo  specified 
in  the  input  data  (i.e. , in  the  DF) , in  the  DD , or  on  a 
user-supplied  file. 

Since  DD's  are  used  in  conjunction  with  block-type  defini- 
tions, they  contain  no  information  about  data  type, 
inversion  status  or  subblock  names. 

Repeating  group  sizes  (i.e.,  number  of  occurrences)  and 
array  sizes  (number  of  words)  can  vary  from  block  to  block 
as  the  user  requires. 


Commands  of  the  LOAD  Module 

Four  commands,  UOF,  SAVE,  UNSAVF  and  FhINT,  are  supported 
by  the  LOAD  module  for  use  in  creating  and  maintaining  DD's  and 
for  identifying  files  that  are  to  be  used  during  the  data  base 
load  process. 

USE  ddname , dfname  ( , dbname ) 

The  iJSK  command  initiates  the  data  base  load  and  identifies 
those  files  which  are  to  be  used  as  inputs  to  the  process.  The 
parameter  ddnamc  is  either  the  name  of  a DD  already  stored  on 
the  data  base,  or  the  name  of  a local  file  containing  a DD. 


37 


other  parameters  include  ^ifr.a’ve,  the  name  of  the  local  DF  file, 
and  fi  >;  j'rr  (optional),  the  name  of  che  local  file  that  contains 
the  names  of  those  blocks  which  will  be  created  and  loaded. 

','E  i i";e 

The  5/, '.’F  command  causes  a DD,  existing  on  a local  file 
identified  in  the  most  recent  USE  command,  to  be  stored  on  the 
data  base  so  it  may  be  invoked  in  a subsequent  data  base  load 
(i.e.,  subsequent  USE  command).  The  parameter  ddna^e  must  be 
a 1-  to  8-character  alphanumeric  string  beginning  with  a letter. 

'..VJ,;  VE  i :>i  € 

The  U. command  causes  a previously  saved  DD  to  be 
removed  from  the  data  base. 

ddK.ir-.e 

The  PRI'IT  command  causes  a previously  saved  DD  to  be 
pr  inted . 

Data  Definition  Statements 

A data  definition  (DD)  may  consist  of  nine  types  of  state- 
ments; these  are  discussed  below. 

."YEE  I inane 

The  TYPE  statement  indicates  that  data  blocks  to  be  loaded 
according  to  the  current  DD  are  of  block  type  btnane.  The  TYPE 
statement  must  precede  all  other  statements  of  a DD. 
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I c K ; t h 


hE  ’ '!•!' 

The  statement,  in  which  the  parameter  length  is  a 

positive  integer  less  than  or  equal  to  80,  indicates  the  length 
of  the  data  in  each  of  the  DF  card  images.  Thus  the  statement 
' f ; 6i  would  indicate  that  data  to  be  loaded  are  contained 
in  Columns  1-50  of  the  DF  card  images;  Columns  51-80  may  contain 
information  such  as  comments  and  end  punching.  If  a RECORD 
statement  is  not  present  in  a DD,  a default  length  of  80  will 
be  used.  When  a RECORD  statement  exists,  it  must  immediately 
follow  the  TYEE  statement. 

:h  'ESC  it  ovec 

The  /.V  'ESS  statement  must  be  the  next  statement  to  appear 
in  a DD.  It  indicates  the  set  of  data  blocks  that  are  to  be 
created  and  loaded  with  DF  data.  The  names  of  the  data  blocks 
may  be  included  in  the  statement,  or  they  may  be  submitted 
separately  with  the  DF  or  by  way  of  a user  file: 

. If  the  names  are  included  in  the  PROCESS  statement , they 
must  be  specified  in  the  order  in  which  the  blocks  are  to 
be  created  and  loaded,  and  they  must  be  separated  by 
commas.  For  example,  PROCESS  BLOCKl , BLOCKL , BL  'CES 
. If  the  names  are  included  in  the  DF,  the  form  of  the 

PROCESS  statement  must  be  either  PROCESS  num  where  num  is 
a positive  integer  indicating  the  number  of  blocks  to  be 
loaded,  or  PROCESS  ALL  in  which  case  all  blocks  named  in 
the  DF  will  be  loaded. 


A 
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If  the  names  are  included  in  a user  file,  the  form  of  the 


statement  must  be  either  I'HOi'F.':'  ku":  in  which  case  the 
first  Ku’".  blocks  named  in  the  i.' file  (identified  in 
the  .'E  command)  will  be  loaded;  or  Ph  'PEP  All  in  which 
case  all  blocks  named  in  the  dlnumc  file  will  be  loaded. 

The  dl  ".a^.e  file  is  a card  image  file,  one  block  name  per 
card  image.  Columns  1-8. 

P TP  ’ Z .T r e <? 

The  py.lP  statement  causes  either  a new  card  image  to  be 
read  from  the  DF  file,  or  a specified  number  of  columns  of  the 
current  DF  card  image  to  be  skipped  (i.e.,  ignored).  If  the 
parameter  eoli^er  is  omitted,  a skip  to  the  beginning  of  the 
next  DF  card  image  is  performed;  if  calsyec  is  a positive 
integer,  that  number  of  columns  of  the  current  card  image  will 
be  skipped. 

e>  I K I'^.e  I .'!  <•  •• 

This  statement  must  be  used  to  load  single-valued  numeric, 

» / 

alphanumeric,  and  pointer  data  elements.  The  parameter  elnane 
must  be  a data  element  name  as  it  appears  in  the  block-type 
definition,  and  the  parameter  a,  /.•>  must  be  a positive  integer 
indicating  the  columnar  width  of  the  data  value.  For  example, 
if  the  data  element  WKICHT  is  a 7-character  value  for  each 
block  to  be  loaded,  then  the  statement  WEI  HIT  7 would  appear  in 
the  DD. 

NOTES:  (1)  If  r.ln'ime  = PN  the  data  field  within  the  DF  will 

contain  the  name  of  the  data  block  (see  explanation 
of  the  PROCESS  statement) . 
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(2)  The  (‘oLppec  for  a data  element  of  type  real  may  be 
specified  i.  as  in  the  F-conversion  format  of 
FORTRAN;  for  example,  the  statement  WEl'lUT  7.2 
signifies  a 7-charactor  value  having  2 digits  to 
right  of  the  decimal.  This  type  of  conversion 
specification  would  be  used  if  the  decimal  were 
not  in  the  DF.  As  in  FORTRAN,  if  the  decimal 
exists  it  overrides  the  o.J.  specification. 

(3)  For  data  elements  of  type  pointer,  any  SCOPE  or 
CPFMS  permanent  file  name-- incl uded  in  the  DF  as 
part  of  a cross-file  poi nter--must  be  parenthe- 
sized and  positioned  just  after  the  block  name;  for 
example,  BLOCKA (pf n , ID=id)  and  BLOCKB { level- 3 , 
level-4 ) . 

. valp]>eo ,eolspea 

This  statement  must  be  used  to  load  array  data  elements. 

The  parameters  elyiar^.e  and  colv.pec  are  as  defined  in  the 
• • statement  described  earlier.  The  parameter  uul.^pc.'  is 

either  a positive  integer,  indicating  the  number  of  values 
comprising  the  array,  or  an  asterisk  {*)  immediately  followed 
by  a positive  integer,  indicating  the  columnar  width  of  that 
data  field  that  specifies  the  number  of  values  comprising  the 
array.  For  example,  if  the  element  WEIGHTS  is  to  contain  six 
8-character  values  for  each  block  to  be  loaded,  then  the  state- 
ment WF:i-;/ITS  6,8  would  appear  in  the  DD;  but  if  WEIGHTS  is  a 
variable-length  array  for  each  block  to  be  loaded,  the  statement 
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*/,'•  would  appear  in  the  DD.  In  this  instance,  a three 
digit  field  within  the  DF  will  specify  the  number  of  values 
comprising  WEIGHTS. 

This  statement  must  bo  used  to  load  data  elements  of  the 
type  text.  The  parameter  l>:ar-  is  the  data  element  name 

as  It  appears  in  the  block-type  definition.  The  parameter 
• ■ is  either  a positive  integer,  indicating  the  number  of 

characters  comprising  the  text,  or  an  asterisk  {*)  immediately 
followed  by  a positive  integer.  This  integer  indicates  the 
columnar  width  of  that  data  field  that  specifies  the  number  of 
characters  comprising  the  text.  For  example,  if  the  element 
EQUIP  is  to  consist  of  49  characters  for  each  block  to  be 
loaded,  tiien  the  statement  r.\,  ' : ■ would  appear  in  the  DD;  but 
if  EQUIP  is  to  consist  of  variable-length  text  for  each  block, 
then  the  statement  .V.,",'.'  would  appear  in  the  DD.  In  this 
instance,  a two-digit  field  in  the  DF  will  specify  the  number 
of  characters  of  text  for  EQUIP. 

r f * 

This  statement  must  be  used  to  specify  the  number  of 
occurrences  that  are  to  be  loaded  for  a repeating  group;  the 
statement  must  precede  the  DD  statements  that  identify  those 
elements  which  will  be  processed  for  the  group  in  the  current 
data  base  load.  The  parameter  rjuuni’  is  the  repeating  group 
name  as  it  appears  in  the  block-type  definition.  The  parameter 
is  either  a positive  integer,  indicating  the  number  of 
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occurrences  of  which  are  to  be  loaded  for  each  block, 

or  an  asterisk  (*)  immediately  followed  by  a positive  integer, 
denoting  the  columnar  width  of  the  data  field  that  specifies 
the  number  of  occurrences  comprising  the  repeating  group. 


The  /'.'.V,' ; statement  must  immediately  follow  the  set  of  DD 
statements  that  identify  those  elements  which  will  be  processed 
for  a repeating  group  in  the  current  execution  of  the  LOAD 
module.  For  every  rgna’^e  statement  (see  discussion 

just  previous)  appearing  in  a DD,  there  must  exist  an  F.V.' ; 
statement . 

Additional  Information  on  Data  Loading 

When  the  value  for  a data  element  in  the  DF  is  found  to  be 
blank,  no  value  will  be  loaded.  In  the  case  of  an  array,  if 
the  values  specification  (denoted  in  the  DD)  is  n (n  0)  but  the 
number  of  non-blank  values  in  the  DF  for  that  array  is  m (m<n) 
then  only  m non-blank  values  will  be  loaded  for  the  block 
currently  being  processed.  If  an  entire  repeating  group 
occurrence  in  the  DF  is  blank,  that  occurrence  is  ignored. 

These  actions  have  two  effects: 

The  user  wishing  to  load  a value  of  0 or  0.0  into  an 
element  (of  type  integer  or  real,  respectively)  cannot 
merely  leave  the  appropriate  field  in  the  DF  blank.  He 
must  provide  the  desired  value. 
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An  element  of  the  type  al  fihanume  r i c , text,  or  pointer 
cannot  be  loaded  (usincj  the  LOAD  module)  with  a field  of 
all  blanks.  If  a user  desires  to  achieve  this  result,  he 
must  use  the  UPDATE  module  after  he  has  loaded  the  other 
values  with  the  LOAD  module. 


D ata  Delinition  and  Pat a File,  an  Example 

The  relationship  between  data  to  be  loaded  (i.e.,  the  DE) 
and  the  data  definition  (DD)  is  best  shown  by  way  of  an  example. 
Hence,  a coordinated  sample,  comprisinq  a block  type,  DD  and 
DF,  has  been  provided.  A brief  discussion  of  the  example 
follows  a listinq  of  the  DF. 


Block  Type  STATES 


STATE 

ALPHA 

(Name  of  the  state) 

YEAPA 

INTEGER 

(Year  of  admission) 

CAPITAL 

ALPHA 

(Capital  city) 

PRESPTR 

POINTER  ARRAY 

(Points  to  blocks  containing  perso- 

nal  data  regarding 
presidents ) 

"native  son" 

AREA 

REAL 

(Area  in  square  miles) 

A REA RANK 

INTEGER 

(Rank  in  area,  1-50) 

POPUL 

INTEGER 

(Popul a t ion ) 

POPRANK 

INTEGER 

(Rank  in  population, 

1 

o 

ELECVOTE 

INTEGER 

(Number  of  electoral 

votes ) 

CITY 

ALPHA 

(Name  of  city) 

ICITY  and  CITYPOP 

CITYPOP 

INTEGER 

(Population  of  city) 

1 const i tute  the 
repeating  group 
CITIES 
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Sample  Data  Definition  (DP) 


TYPE  STATES 
RECORD  62 
PROCESS  50 
BN  8 
SKIP 

STATE  10 
SKIP  5 
YEARA  4 
SKIP  5 
CAPITAL  10 
SKIP 

PRESPTR  *2,10 
SKIP 
AREA  10 
SKIP  3 
AREARANK  2 
SKIP  6 
POPUL  8 
SKIP  3 
POPRANK  2 
SKIP  6 
ELECVOTE  2 
SKIP 

CITIES  *2 
CITY  10 
SKIP  2 
CITYPOP  8 
SKIP 
ENDRG 


Sample  Data  File  (DF) 


TEXAS 


I 


TEXAS 

1845 

AUSTIN 

2EISENHOW 

JOHNSONL 

267339 . 45 

2 11196730 

4 

10 HOUSTON 

1232802 

DALLAS 

844401 

SANANTONIO 

654153 

EORT  WORTH 

193476 

EL  PASO 

322261 

AUSTIN 

251808 

CORP.  CHR. 

204525 

LUBBOCK 

149101 

AMARILLO 

127010 

BEAUMONT 

VIRGINIA 

117548 

VIRGINIA 

1788 

RICHMOND 

7WASHINGT 

WILSON 

JEFFERSO 

MADISON 

MONROE 

40  31  5.  18 

36 

4648494 

14 

7NOREOLK 

307951 

RICHMOND 

249430 

VA.  BEACH 

172106 

NLWP.  NEWS 

138177 

HAMPTON 

120779 

PORTSMOUTH 

110963 

ALEXANDRIA 

INDIANA 

110938 

INDIANA 

U 

3629  1 . 30 

1816 

I NDI ANAP 

• 

3 8 

5193669 

11 

6INDIANAP. 

744743 

FORT  WAYNE 

178021 

GARY 

175415 

EVANSVILLE 

1 38764 

SOUTH  BEND 

125580 

HAMMOND 

NH 

107888 

N.  H . 

1788 

CONCORD 

IPIERCE 

9304.89 

0 

WVA 

44 

737681 

42 

W.  VA. 

0 

24181  .73 

1863 

CHARLESTON 

41 

1744237 

34 

0 


26 


HARRISON 


12 


13 


4 


6 


TYLER 
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In  the  example  provided,  the  DP  contains  data  for  50  blocks 


(but  to  conserve  space  only  data  for  5 of  the  50  are  shown) - 
These  data  blocks,  one  for  each  of  the  50  states  (note  that 
the  statement  B.V  H in  the  DD  indicates  that  block  names  are 
within  the  DP  data),  are  variable  in  length  because  of  the 
varying  size  of  the  array  FRESPTR  and  the  varying  number  of 
occurrences  of  the  repeating  group  CITIES.  Por  example,  for 
the  block  TEXAS  there  are  two  values  in  the  array  PRESPTR; 
for  VIRGINIA  there  are  seven  values;  INDIANA  has  no  values, 
as  indicated  by  a zero  in  the  valr'.cr  field;  NH  (New  Hampshire) 
has  one  value  for  PRESPTR;  and  WVA  (West  Virginia),  like 
INDIANA,  has  no  values,  again  indicated  by  a 0 in  the  ''ll.".  ■'  • 
field.  Por  each  block  the  number  of  values  for  PRESPTR  is 
found  in  Columns  1-2  of  the  card  image  following  the  one 
containing  data  for  the  elements  STATE,  YEARA  and  CAPITAL. 

The  number  of  occurrences  of  the  repeating  group  CITIES  is 
found,  for  each  block,  in  Columns  1-2  of  the  card  image 
following  the  one  containing  data  for  AREA,  AREARANK,  POPUL, 
POPRANK  and  ELECVOTES.  Thus  we  see  that  TEXAS  has  ten 
occurrences  of  CITIES,  VIRGINIA  has  seven,  INDIANA  has  six, 
and  NH  and  WVA  have  none,  as  indicated  by  a 0 in  the  oeuupcc* 
field. 

3.  The  UPDATE  Module 

The  UPDATE  module  allows  the  user  to  print,  lelete,  create, 
modify  and  add  data  for  the  active  data  base  file.  Several 
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terms  used  in  describing  the  individual  commands  of  the  UPDATE 
module  need  to  be  defined: 


Data  block  name  list  .il’na’vi  litM)  - The  names,  separated 
by  cemmas,  of  one  or  more  data  blocks  which  are  to  be 
processed  (for  example,  BI  "KA,  b:  'KB,  BL  ’KC);  a block 
type  name  bound  in  quotation  marks  (for  example,  "rWB."') 
signifying  that  all  blocks  of  a given  type  are  to  be 
processed:  or  ABi  indicating  that  all  blocks  in  the  data 
base  file  are  to  be  processed.  When  the  user  issues  a 
command  in  which  a block  type  name  or  ALL  is  specified, 
he  will  receive  a message  indicating  the  number  of  blocks 
which  will  be  processed;  he  will  then  be  asked  to  verify 
or  cancel  his  command. 

Data  block  item  list  {Jbite'r.Liat)  - A subblock  name, 
repeating  group  name,  or  data  element  name,  or  a combi- 
nation of  these  names  separated  by  commas;  for  example, 

KL . . KL : . B ; ; , kl b . 

Occurrence  number  list  (ocjc".u’^be  r li  :)  ~ Either  an  integer, 
signifying  a repeating  group  occurrence  number,  or  two 
integers  separated  by  a hyphen,  indicating  a range  of 
occurrence  numbers,  or  a combination  of  these  forms 
separated  by  commas;  for  example,  1 , 1. , A - , 1 B , 1 f" . 


Camands  of  the  UPDATE  Module 


PB.INT  D Hi- 1 / 'M  i i t /o-'''y’nn} at. 


Exanfiles: 


PRim’  BLOCKA 

PRim  BI£)CKA,BlJ[X:3<B/ELl 

PRUTT  BIiOCKA/llLl,EL2,RGl 

PRirfr  BIiXKA/FX5,EL6/3,4 

PRIl/r  BLDCKA/R(ll/j-f),8 


(Print  the  entire  contents  of  the  data 
block  BirxiKA. ) 

(Print  the  data  eltanent  ELI  of  tlie  data 
blocks  BliXnCA  and  BliXTKB. ) 

(Print  all  occurrences  of  the  elements  EILl 
and  EL2  and  the  repeating  (froup  RGl  of  the 
data  block  BI/XTKA. ) 

(Print  the  third  and  fourth  occurrences  of 
tlie  elarents  ELS  and  EL6  of  the  block 
BI/XTKA. ) 

(Print  the  third,  fourth,  fifth,  sixth,  and 
eighth  occurrences  of  all  data  elements  in 
the  refjeatincj  ijroup  RGl  of  the  block  BIIXZKA. ) 
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PRINT  "I?n"/EL5 


(Print  the  data  elanent  ELS  of  all  data 
blocks  of  the  block  tyjie  OTl . Before  tlie 
retjuest  will  be  prrxressod,  the  user  will 
have  to  respond  to  the  tjuestion  THERE  ART; 
nnn  HATA  BLOCKS  TD  Bi:  PRCXCESSED,  SHAll.  Wi; 
COWTINUE?) 

PRINT  ALL  (Print  the  entire  contents  of  ever/  data 

block  contained  on  this  data  base  file. 

As  in  thf'  previous  ex^iir^jle,  printinq  will 
occur  when  an  affirmative  answer  to  the 
question  is  sufjplied. 


F.LF.'7F  (It  yimelisti'dF  i te^ilir,  t/orrynunhprli!'  t / * 


To  guard  against  accidental  deletion  of  data,  all  7'FLFTF  comrands  mist 
be  verified  before  they  are  processed;  that  is,  the  user  is  asked  if  his 
intentions  were  properly  expressed  in  his  ' FFF7F  comrand.  The  optional 
asterisk  (*)  included  at  the  end  of  the  ccTtrrand  signifies  the  user's  desire 
to  inspect  the  values  of  those  itcans  to  be  deleted  prior  to  contrand  verifi- 


cation; the  asterisk  serves  the  same  purjxise  as  consecutive  • .'.V. ; 


comrands. 


Examples: 


LEIJ-rTE  BLDCKA 
DEIJ^TE  "HTl" 

DEUnE  BliXWELl 

DELETE  BbDCKA/RCl/3,4,6 


(Delete  tire  data  block  BliXKA. ) 

(lielete  all  data  blocks  of  the  type  BTl.) 

(Delete  the  elcament  ELI  from  the  data  block 
BLDCKA;  if  ELI  is  a member  of  a repeating 
group,  all  occurrences  will  be  deleted.) 

(Delete  the  third,  fourth,  and  sixth 
occurrences  of  the  repeating  group  RGl  of 
the  block  BIjCXTKA.  ) 


DELETE  BLr)CKA/EL5,EL6/6-9/*  {The  values  of  the  sixth  through  the  ninth 

occurrences  of  FJ,5  and  EL6  will  be  printed. 
The  user  will  then  be  asked  to  \'erify  the 
deletion. ) 
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:f  K i’’-  .• 

}-y.ar[\>]cs: 

CRI-^Tl',  BIiXTKA.^I<l’l  (Cro.itf'  d ikv;  daUi  block  of  block  type 

KI'l  ari'l  Hiunf  the  block  Bl/iCK/'i. ) 

Ciy-lA'n-;  BliX'KA.BIiX’KB/B'rl  (Cr<.‘ate  dat^i  blcx^ks  and  BliJCJKH 

o!  blfx-k  t •_.7X‘  BTl . ) 


VVliexi  usinii  tlio  ■ c^xurand  tlx-  user  will  bt'  pn)m(jted  for  those  data 

values  he  desires  insert<xl  into  the  data  base. 


Ilxamjjles : 

MDDII’Y  BIlX-'KA/FJd  (Tlie  user  will  ixi  f^ronifiterl  for  a value 

or  u set  of  values  which  will  be  u.sed 
as  Uie  new  contents  of  the  data  element 
IlJ  in  the  blexrk  BIIXJKA. ) 

MfXlIIT  Bl£)CKA/H(')l/3  ('Ihe  tliird  occurrence  of  the  repeatinej 

<^jmu()  FX:i  IS  to  Ijc  nrxlifif.'d.  The  user 
will  lx?  pniniiJted  for  now  values  for 
each  of  the  mrrlxir  elements  in  the 
retxvitinq  (jroup.  If  a value  for  one  of 
these  elements  is  not  to  Ix'  modified, 
tlien  the  aser  mist  resixiiKi  with  the 
notation  instead  of  a value.  It) 
illustrate,  supjxise  RC.l  consists  of  the 
ehantnts  AA,  BB  and  tX\  Tfie  user  will 
be  asktxl  to  provide  a value  for  each  of 
tho.se  eltsnents.  If  the  value  of  an 
element,  .say  BB,  is  not  to  be  modified, 
thin  the  user  must  resiond  with  00.) 

MDDIFY  BI/lCKA/FlL3,flI>},EL5/*  (The  values  of  the  three  data  elements 

will  lx?  printexi,  and  the  user  will  then 
be  promjited  for  new  values.  If  a value 
is  not  to  be  mcxlificxl,  the  user  merely 
enters  the  notation  00  instead  of  a 
valut'.  If  one  of  tlie  eltments,  say 
VIA,  was  a rntmlxir  of  a reixiatinq  qrouii, 
th»^  user  would  be  asked  to  provide  a 
valix?  ffir  every  occurrence  of  I1L4  since 
no  <'i-'-nurib,’vl  i.'-t  was  specified. 
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ADD  lil mrtt'L  ' f t/dl  i tcnl  it-:  t 

The  ADD  conmanci  will  add  either  a new  ('xxnirrence  txj  a repxiatinq  '■froup, 
or  a locally  defined  data  element  to  a data  block..  Nlodif ication.s  to  non- 
repeatinq  group  defined  elements  must  Ix'  made  by  way  of  the  ’ ctyrmond, 

whether  or  not  the  data  element  has  Ixien  loaded  previously. 

As  with  the  Mi'DIFY  camand  the  user  of  tlio  ' comvind  will 
proriJtGd  for  those  values  he  desires  insertcxl  into  the  data  lase. 
r;xanp>les : 

ADO  BLOZKA/RGl 


ADD  BIOrKA/I/1CEU,LCX33L2 


4,  The  QUERY  Module 

The  QUERY  module  allows  the  user  to  generate  "hit"  files 
(i.e.,  files  containing  names  of  data  blocks  stored  on  the 
active  data  base  file(s)  that  satisfy  certain  user-specified 
criteria),  and  to  print  values  retrieved  from  blocks  named  on 
the  "hit"  file. 

Before  specifying  his  "hit"  file  criteria,  the  user  must 
already  have  activated  the  data  base  file(s)  (as  many  as  five 


(Add  a new  occurrence  to  the  repeating 
cjroufi  RGl  of  data  block  BL/OCKA.  The 
user  will  be  pronpted  for  element  values 
in  the  manner  described  for  the 
conrrond.  If  no  I'alue  for  one  of  these 
elements  currently  exists,  the  user 
must  respond  with  the  notation  To 

illustrate,  .suppo.so  RGl  consists  of 
the  elements  AA,  BB  and  CC.  The  user 
will  be  asktxi  to  provide  a value  for 
each  element.  If  the  value  for  an 
element,  say  BB,  does  not  exist,  the 
user  responds  witli  AC.) 

(Add  the  locally  defined  data  elements 
DDCELl  and  UXTld  to  block  BLOCKA.  The 
user  will  be  pron^Jted  for  the  needed 
data  values. ) 
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may  be  inclicateii)  Msinq  the  file  mannqemcnt  command  ' '.'AhA.'F . 
Note  that  only  while  in  the  OUbRY  modulo  may  the  user  specify 
more  than  one  file  in  the  ' A '."A  hA:' !■'  command.  Moreover,  if  the 
user  has  more  than  one  data  base  file  active  at  the  time  he 
exits  the  yUi;RY  module  to  enter  another  module,  all  files  will 
be  "deactivated"  and  there  will  be  no  active  file  until  one  is 
specified  in  a subsequent  J’AT.AHASF  command. 

Commands  of  the  QUE RY  Module 

The  QUERY  module  F t command  allows  a user  to  interrogate 
the  active  data  base  file(s)  and  to  generate  the  initial  QUERY 
hit  file,  or  a new  hit  file  that  will  replace  the  current  hit 
file.  The  QUERY  module  'HA,.i  command  allows  the  user  to 
traverse  intra-file  and  cross-file  pointers.  Beginning  with 
those  data  blocks  named  in  the  current  hit  file,  the  traversal 
process  may  progress  through  up  to  eight  different  pointer 
elements  resulting  in  a new  hit  file.  The  command 

allows  a user  to  generate  a new  hit  file  that  is  a subset  of 
the  current  hit  file. 

The  QUERY  module  also  suptiorts  several  auxiliary  commands, 
FA'AF,  'i.'AVF,  HIT:',  BAT''H  and  FHI'HAT  'H,  which  allow  a user  to 
manipulate  hit  files  and  to  store  QUERY  commands  on  a queue 
for  subsequent  execution. 

The  QUERY  module  PRINT  command  allows  a user  to  retrieve 
values  from  data  blocks  named  in  the  current  hit  file  a 1 to 
print  these  values  in  one  of  three  report  formats:  columnar, 
row  and  simple  list. 

I 
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QUERY  commands  may  be  three  lines  lonq  (a  line  may  contain 
as  many  as  80  characters).  An  ampersand  { s. ) entered  as  the 
last  non-blank  character  of  a line,  indicates  a continuation. 


F r.  h : ‘ L'fi  t r r i a 

The  F:'r  command  initiates  generation  of  a hit  file  using 
information  contained  in  the  active  data  base  file(s).  Note 
that  this  is  the  only  command  that  can  generate  the  initial  hit 
file.  If  a hit  file  already  exists  (resulting  from  a previous 
FOR,  'RAFF  or  .yAAI.-'FY  command)  and  it  has  not  been  saved  (see 
the  discussion  of  the  command),  it  will  be  unloaded  when 

the  new  hit  file  is  generated. 

Acceptable  n i i : I ■ t>  ' i for  the  •'  ••  command  are  as 

follows : 

(i)  A relational  expression,  written  either  as 

• r.  r> 

in  which  case  the  relational  operator  must  be  . . ,.  .\'F.  , 

• r.  ' ' L'  ..  ' ' 

or  .RFT.  valu^'.,  ‘ 

in  which  case  the  operator  .FFT.  indicates  that  only 
values  within  the  range  defined  by  and  : 

inclusive  will  be  considered. 

Note  that  in  a relational  expression  the  parameter 
-■•Iname  must  be  the  name  of  an  inverted  data  element, 
and  that  whenever  a value  is  alphanumeric  it  must  be 
bound  in  quote  marks  ("). 

(ii)  A block  type  expression  written  as 
RT  Ftnimt' 

where  I tna'nr  is  the  name  of  a block  type  stored  on  the 
active  data  base  filo(s). 

(iii)  The  name  of  a saved  hit  file. 


(iv)  A list  of  data  block  names  separated  by  commas.  The 
list  must  beqin  and  end  with  a slash;  for  example, 

FLOCKA,  BLOCK':, 

(v)  Any  combination  of  expressions  (i)  through  (iv) 
connected  by  the  Boolean  operators  .AC  . or  . 
Expressions  may  be  enclosed  in  parentheses  when  it  is 
necessary  to  alter  the  normal  .AL'i.  before  . B. 
precedence . 

Examples : 

FOR  HEIGHT  . GT . "6FT." 

FOR  /LINCOLN,  KENNEDY/ 

FOR  HEIGHT  .GT.  "6FT."  .AND.  FILEX  .OR.  /LINCOLN/ 

FOR  SURNAME  .BET.  "ADAMS",  "LINCOLN"  .AND.  YEARB  . GT . 
1799 

"A  L 1 F y hi  * Ipc  r'i  tc  ri  a 

The  .'ALiFY  command  allows  a user  to  generate  a new  hit  file 
that  IS  a subset  of  the  current  hit  file  (i.e.,  the  file 
resulting  from  a previous  FOB,  CHASE  or  OUALIFY  command). 

If  the  user  specifies  a search  on  a non-inverted  element,  he 
IS  given  a message  specifying  the  number  of  data  block  accesses 
that  must  be  made  in  order  to  satisfy  the  non-inverted  search, 
and  he  is  asked  to  verify  whether  he  wishes  to  continue  the 
search  procedure.  The  user  should  be  aware  that  non-inverted 
searches  may  be  quite  costly  and  he  should  therefore  act 
accordingly . 

Acceptable  hi  t fi  If-cr'  teria  for  the  QUALIFY  command  are  as 
fol lows : 

(i)  A relational  expression  as  described  for  the  FOB 
command  except  that  elname  can  be  the  name  of  any 
s i ng 1 e- va 1 ued , non-inverted  data  element. 
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(ii)  Any  combination  of  relational  expressions  connected  by 
the  Boolean  operators  . or  . r:.  The  normal  prece- 
dence of  . hVP.  before  . • ■ . may  be  altered  by  enclosinq 

expressions  in  parentheses. 

Examples : 

FOR  HEIGHT  . GT . "6FT."  .AND.  FILEX  (The  user  qenerates  a 

hit  file.) 

QUALIFY  YEARR  .BET.  1700,1896  (The  user  (lualifies  the 

hit  file  qene rated  by 
the  above  ■ command.) 

QUALIFY  INITIAL  .EQ.  "Q."  (The  hit  file  generated 

by  the  ..'lALIFY  command 
is  cjual  i f ied . ) 

CHASE  ptpspee 

The  ‘''HACK  command  allows  a user  to  trav'erse  intra-file  and 
cross-file  pointers.  Beginning  with  those  data  bloclcs  in  the 
current  hit  file,  the  traversal  process  may  progress  through  up 
to  eight  different  pointer  elements  and  will  result  in  a new  hit 
file.  The  parameter  ••tpci-p.j  is  a list  of  up  to  eight  pointers 
separated  by  slashes;  for  example,  PTR 1 /PTRP./FTP:-' . 

If  a cross-file  pointer  is  encountered,  the  file  pointed 
out  will  also  be  processed  providing  one  of  the  following  three 
conditions  is  satisfied; 

It  has  been  attached  with  the  file  management  command 
attach. 

. It  has  not  been  attached  and  does  not  have  a password. 

. It  has  not  been  attached  and  the  user  can  supply  the 
appropriate  password. 

In  the  first  two  cases  the  processing  will  continue  without 
interruption.  In  the  third  case,  the  user  will  be  prompted  for 
the  password. 

f 
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Examples : 

CHASE  STATEPTR  (Consider  a data  base  containing 

information  about  the  U.S.  presi- 
dents. Consider  also  that  block 
types  ELECTION  (containing  a 
pointer  PRESPTR) , PRES  (containing 
a pointer  STATEPTR)  and  STATE  are 
stored  on  the  data  base.  If  the 
current  hit  file  contains  two  data 
blocks,  JACKSON  and  MADISON,  then 
this  command  will  generate  a hit 
file  containing  the  block  names 
SC  and  VIRGINIA.) 

CHASE  PRESPTR/STATEPTR  (If  for  the  presidents  data  base 

the  current  hit  file  contains  the 
block  names  E1960,  E1964,  E1968, 
E1972  and  E1976  (data  blocks 
containing  information  relative  to 
the  presidential  elections  for  the 
years  1960-76) , then  this  command 
will  generate  a hit  file  containing 
the  names  MASS,  TEXAS,  CAL  and 
GEORGIA. ) 


SA  VE  Ifn 

The  SAVE  command  allows  a user  to  assign  a name  to  the 
current  hit  file  and  to  save  the  file  for  subsequent  process- 
ing; the  parameter  Ifn  is  the  user-supplied  file  name.  A 
saved  hit  file  can  be  referenced  in  a FOR  command  at  any  time. 
The  user  should  note  that  saved  hit  files  (and  the  current  hit 
file  for  that  matter)  can  become  meaningless  if  the  data  base 
file(s)  is  unloaded  (via  the  UNLOAD  command)  even  though  the 
hit  files  may  still  exist. 

UNSAVE  Ifn 

The  UNSAVE  command  unloads  the  specified  saved  hit  file 
(Ifn)  and  frees  the  name  for  reuse  in  a subsequent  SAVE  command. 
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The  H!"'':'  command  returns  the  number  of  hits  (i.e.,  block 
names)  on  a specified  saved  hit  file  / f>i , or  on  the  current 
hit  file  when  the  parameter  Ifn  is  omitted  from  the  command. 

HAT  ■// 

The  HAT  'H  command  allows  a user  to  submit  QUERY  commands 
and  to  have  them  checked  for  syntax  and  stored  on  a queue  for 
subsequent  execution.  This  feature  enables  the  user  to  leave 
his  terminal  while  a set  of  commands  is  executing.  After  a 
HA"  command  has  been  issued,  each  succeeding  command  will  be 
checked  for  syntactical  validity  (diagnostics  are  printed  as 
necessary)  and  will  then  be  stored  on  a command  queue. 

hw:  HA  TCH 

The  H'JHBAT  'H  command  causes  the  QUERY  module  to  execute  in 
sequence  those  commands  which  have  accumulated  on  the  command 
(jueue  as  a result  of  the  /U17'  ’//  command  (see  above).  When  the 
last  command  on  the  queue  has  been  executed,  QUERY  waits  for  the 
user  to  enter  another  command. 

HHI  NT  pt'int  t-ppr 

The  HR! NT  command  allows  a user  to  retrieve  values  from 
data  blocks  named  in  the  current  hit  file  and  to  have  these 
values  printed  either  on  his  terminal,  on  a report  file,  or  at 
both  destinations  (see  the  discussion  of  the  auxiliary  command 
nVTl'llT).  In  addition,  the  HRJNT  command  allows  the  user  to 
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perform  simple  arithmetic  operations;  to  sort,  average  and 
sum;  and  to  specify  an  output  format  of  either  columnar,  row, 
or  simple  list. 


The  parameter  pyintapcc  may  consist  of  up  to  three  items 
written  as 

forma!  o I Hanoi  is t s-r taper 

where  the  item  elnanelist  identifies  those  entities  which  are 
to  be  printed,  and  forma*  and  sortspec  denote  a report  format 
and  sort  specification,  respectively.  A more  detailed  descrip- 
tion of  the  three  printspec  items  follows: 

fo rma t - If  the  report  format  is  to  be  a simple 
list,  then  f mat  must  be  omitted  from  the  printapea . 

If  a columnar  report  format  is  required,  format  must  be 
the  designation  IN  COLT-  in  which  case  data  values  will  be 
printed  in  columns  (up  to  five  for  the  user's  terminal; 
eight  for  the  report  file)  and  those  data  element  names 
specified  in  the  elnanelist  will  appear  as  column  head- 
ings. If  a row  format  is  required,  format  must  be  the 
designation  !N  HOW.'t  in  which  case  values  will  be  paired 
with  their  data  element  names  (from  elnan>  list)  and 
printed  in  row  fashion  (up  to  three  pairs  per  line  for 
the  terminal;  five  pairs  for  the  report  file). 

c I name  list  - The  following  entities  may  appear  in 
an  elnanelist:  DB  (denoting  data  base  name),  BT  (denoting 
block  type  name),  BN  (denoting  data  block),  data  element 
names  and  repeating  group  names  as  they  appear  in  the 
block-type  definition,  and  parenthesized  arithmetic 
operations  involving  two  valid  data  elements.  (The  two 
data  elements  of  an  arithmetic  operation  must  be  of  the 
same  block  type  and  must  be  single-valued  and  of  type 
numeric;  if  repeating  group  elements,  they  must  be 
members  of  the  same  repeating  group.)  An  arithmetic 
operation  is  written  as  one  of  the  following: 

(e  Inane  I + e Inane  S)  Sum  of  el  name  I and  e Inane'.’ 

(e  Inane!  - elnaneP.)  Difference 
(e Inane!  * e Inane  2)  Product 
( elname ! / elnaneP)  Quotient 

where  elnanel  and  elnamcP  are  valid  data  element  names; 
the  names  need  not  appear  as  individual  data  elements  in 
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the  If  the  Sum  and/or  averaqe  of  any  single- 

valued,  numeric  element  is  to  be  calculated,  the  . 
may  include  the  designations  r '''-o  7 num.  j and/or  A VK  f r ■ ni'^r  } . 

Entities  appearing  in  an  . ,’ >■  u ' must  be  separated  by 

commas.  When  ' ' ' is  specified  in  the  /'  the 

• may  include  only  , /tV  and  a set  of  data 

element  names;  the  data  elements  must  be  single-valued 
and  must  either  be  non-repeating  cjroup  elements,  or 
members  of  the  same  repeating  group. 

■')  r * ■ ‘ - The  optional  parameter  .•  is 

valid  only  when  ’ is  specified  in  the  / r-m ; ' . The 
,•  r'. identifies  the  ascending  (i.e.,  ;V'//7)  or 
descending  w ' order  in  which  a set  of  data  elements 
will  bo  sorted;  those  elements  named  in  the  - 

must  also  be  named  in  the  . Ini"-,  i ' . A u i-', must  be 

written  as 

’ . . . 


where  cl  n ire!  and  eLna^'e'.:  are  element  names.  When  more 
than  one  sort  is  specified,  the  first  (i.e.,  rZr'zm.  ;)  is 
the  most  significant.  The  brackets  ([!)  indicate  that 
the  user  must  make  a choice  between  the  designations 
///;//  and  L W for  example,  SDHTED  Oil  HI  III  AA , L W HP. 


Examples  : 

(1)  The  command  PRINT  IN  COLS  WEIGHT,  LENGTH,  COST  will 
result  in  the  following  arrangement: 

WEIGHT  LENGTH  COST 


300 

400 

500 

60 

70 

800 

700 

60 

90 

The  command 

PRINT 

IN  ROWS 

LENGTH,  WEIGHT,  COST, 

DEPTH,  AREA 

will 

result  in 

the  following  arrangement: 

LENGTH 

: 400 

WEIGHT: 

300  COST:  500 

DEPTH: 

400 

AREA: 

600 

70  WEIGHT: 
100  AREA: 


LENGTH: 
DEPTH : 


60  COST:  800 
400 


I 


(3)  The  command  PRINT  WEIGHT,  LENGTH,  COST  will  result 
in  the  following  simple  listing: 

WEIGHT  300 

LENGTH  400 

COST  500 

WEIGHT  60 

LENGTtf  70 

COST  800 

5.  The  STATS  Module 

The  STATS  module  furnishes  the  user  with  statistics  about 
the  various  data  blocks,  block  types,  data  definitions  and 
inverted  data  elements  (i.e.,  the  keys)  stored  on  the  active 
data  base.  After  he  enters  the  STATS  module,  the  user  ’c 
informed  as  to  how  many  data  blocks,  block  types,  data  defini- 
tions and  keys  are  included  on  the  data  base;  the  user  may 
then  request  more  detailed  information  related  to  each  of 
these  items. 

Commands  of  the  STATS  Module 

Eight  commands,  ’’S.V/LVEJ,  R.' ''/-.'I , R .".V/i S , 
rr";  , rl!-:  Y :■  A S i F , .Vi';'.  and  ATF,  are  supported  by  the 

STATS  module. 

.•'.V/  y'r  . ' t t j'rr  . ' ‘ 

The  FUAMKr  command  allows  the  user  to  print  the  names 
of  the  data  blocks  of  a subset  of  the  active  data  base.  The 
parameter  }tn<i’nelic,t  consists  either  of  one  or  more  block 
type  names,  separated  by  commas;  or  of  the  word  ALL, 
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indicatinq  that  the  names  of  all  cJata  blocks  on  the  active 
data  base  file  are  to  be  printed. 

Example : 

DBNAMES  PRES,  ELECTION  (Print  the  names  of  all  blocks 

of  the  block  type  PRES  and  the 
block  type  ELECTION.) 

' .V:  'I * 

The  command  allows  the  user  to  obtain  an  octal 

printout  of  the  data  blocks  for  a specified  subset  of  the 
active  data  base.  The  parameter  Jur^}r  t'.;  -''c  must  be  either  one 
or  more  block  names,  separated  by  commas;  or  the  names,  each 
enclosed  in  quote  marks  and  separated  by  commas,  of  one  or 
more  block-type  definitions:  or  AL! , indicatino  that  all 
blocks  on  the  data  base  file  are  to  be  printed. 

Examples : 

DBDUMP  LINCOLN  (Print  the  contents  of  the  data 

block  named  LINCOLN.) 

DBDUMP  "PRES",  "ELECTION"  (Print  the  contents  of  all 

blocks  of  block  types  PRES  and 
ELECTION. ) 

BTNAy.E:' 

The  FiTNAMHS  command  allows  the  user  to  print  the  names 
of  the  block-type  definitions  stored  on  the  active  data  base; 
the  number  of  data  blocks  is  printed  adjacent  to  each  block 
type  name. 
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V/t.Vf’/j 

The  command  allows  the  user  to  print  the  names 

of  the  data  definitions  stored  on  the  active  data  base. 

The  KF.Yh’AMKS  command  allows  the  user  to  print  the  names 
of  the  inverted  data  elements  (or  keys)  stored  on  the  active 
data  base. 

'F K Y /?  .V  i F r>  keuna^i e I i c t 

The  FFYht\F  ;E0  command  allows  the  user  to  print  the  number 
of  values,  the  lowest  value  and  the  highest  value,  for  a sub- 
set of  the  keys  stored  on  the  active  data  base.  The  parameter 
k . _-nirne  li  i' t must  be  either  one  or  more  names,  separated  by 
commas,  of  the  keys  whose  ranges  are  to  be  printed;  or  AiLL 
indicating  that  the  ranges  of  all  keys  are  to  be  printed. 

KF.YF'FAF  ke^tnane  Up  t 

The  KFYFFF.P  command  allows  the  user  to  print  all  values 
for  a subset  of  the  keys  stored  on  the  active  data  base.  The 
parameter  . -i  n ire  I { a t must  be  either  one  or  more  names, 
separated  by  commas,  of  the  keys  whose  values  are  to  be 
provided,  or  ALL,  indicating  that  the  values  of  all  keys  are 
to  be  printed. 

L‘A  TE 

The  DATE  command  allows  the  user  to  print  the  date  and 
time  at  which  the  active  data  base  file  was  created,  and  the 
date  and  time  at  which  the  file  was  last  compressed. 
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6. 


The  DUMP  Module 


The  DUMP  module  allows  the  user  to  dump  the  contents  of 
data  blocks  onto  a card  image  file  (DF)  formatted  as  described 
by  a data  definition  (DD) . The  DUMP  module  provides  the 
following  features: 

The  user  can  save  DD's.  A saved  DD  can  be  used  at  a 
later  time  to  dump  another  set  of  blocks  and/or  create 
and  load  a set  of  blocks.  (See  the  description  of  the 
LOAD  module  for  a discussion  of  the  data  base  load 
process.)  A saved  DD  can  be  printed  on  request. 

The  names  of  the  data  blocks  to  be  dumped  can  be  speci- 
fied in  the  DD  or  on  a user-supplied  file. 

The  amount  of  space  allotted  in  the  DF  for  repeating 
groups  and  arrays  can  vary  from  block  to  block  depending 
on  the  number  of  occurrences  in  the  repeating  groups  and 
the  number  of  values  in  the  arrays. 

Commands  of  the  DUMP  Module 

■ ifnirni:  [,:Una"ic] 

The  ".'F  command  initiates  the  data  base  dump  and  identi- 
fies those  files  which  are  to  be  used  in  the  process.  The 
parameter  is  either  the  name  of  a DD  already  stored 

on  the  data  base,  or  the  name  of  a local  file  containing  a DD. 
Other  parameters  include  Ifnanc , the  name  of  the  local  DF 
file,  and  dt.narrc  (optional),  the  name  of  the  local  file  that 
contains  the  names  of  those  blocks  to  be  dumped. 

FA  VF 

The  :'>AVF,  command  causes  a DD,  existing  on  a local  file 
identified  in  the  most  recent  USE  command,  to  be  stored  on  the 
data  base  so  it  may  be  invoked  in  a subsequent  data  base 
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dump  (i.e.,  subsequent  USE  command).  The  parameter  ddname 
must  be  a 1-  to  8-character  alphanumeric  string  beginning  with 
a letter. 

i'XSAVF  ddna'vr 

The  "NSAVF  command  causes  a previously  saved  DD  to  be 
removed  from  the  data  base. 

i'hlNT  ddnarne 

The  PRINT  command  causes  a previously  saved  DD  to  be 
printed. 

Data  Definition  Statements 

TYPE  Ilnr-.e 

The  FYl F statement  indicates  that  data  blocks  to  be 
dumped  according  to  the  current  DD  are  of  block  type  ttnanc. 
This  statement  must  precede  all  other  statements  of  a DD. 

RECORD  len.jth 

The  RE  'ORD  statement,  in  which  the  parameter  length  is  a 
positive  integer  less  than  or  equal  to  80,  indicates  the 
length  of  the  data  string  in  each  of  the  DF  card  images.  Thus 
the  statement  RECORD  bO  would  indicate  that  the  data  being 
dumped  is  to  be  contained  in  Columns  1-50  of  the  DF  card 
images.  If  the  RECORD  statement  is  omitted  from  a DD,  a 
default  length  of  80  will  be  used.  When  a RECORD  statement 
exists,  it  must  immediately  follow  the  TYPE  statement. 


64 


The  ! •■'0  'F:'r  statement  must  be  included  in  a DD.  It  indi- 
cates the  set  of  data  blocks  whose  values  are  to  be  dumped  to 
the  DF.  The  names  of  the  data  blocks  may  bo  included  in  the 
statement,  or  they  may  bo  submitted  separately  by  way  of  a 
user  file.  The  user  may  request  the  dumping  of  all  blocks  of 
the  typo  specified  in  the  TYI  !■’  statement. 

If  the  names  are  included  in  the  FF  'EFT  statement , they 
must  be  specified  in  the  order  in  which  the  blocks  are  to  bo 
dumped,  and  they  must  be  separated  by  commas.  For  example, 

.•  ■ ■ 'K  : , HI.:  rKr, , FLOrK,^ . 

If  the  names  are  included  in  a user  file,  the  form  of  the 
statement  must  be  either  P.F  'f'ESL'  nur  in  which  case  the  first 
Ku’^.  blocks  named  on  the  din.i'ne  file  (identified  in  the 
command)  will  be  dumped,  or  F'HO  'ESG  ALL  in  which  case  all  blocks 
named  on  the  ilmr;,  file  will  be  dumped.  The  .il  k ir-.p  file  is  a 
card  imago  file,  one  block  name  per  card  imago,  columns  1-8. 

If  all  blocks  of  a certain  type  (as  indicated  in  the  "YI'F. 
statement)  are  to  be  dumped,  the  form  of  the  statement  must  bo 
F'-'  ''F:'G  ALL  and  no  dhuaivi-  file  need  be  specified  in  the  :'F 
command . 

GRIP  ('oli'.pec' 

The  GKIV  statement  either  causes  the  current  card  image 
to  bo  written  to  the  DF  file,  or  causes  a specified  number  of 
columns  of  the  current  DF  card  image  to  be  skipped  (i.e., 
ignored).  If  the  parameter  ceZ.'gu’c  is  omitted,  the  card  image 
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built  in  memory  will  be  written  to  the  DF;  if  is  a 

positive  integer,  that  number  of  columns  in  the  card  image 
buffer  will  be  skipped. 

elK.i'nc  colspea 

This  statement  must  be  used  to  dump  single-valued  numeric, 
alphanumeric,  and  pointer  data  elements.  The  parameter  elna-ve 
must  be  a data  element  name  as  it  appears  in  the  block-type 
definition,  and  the  parameter  colspea  must  be  a positive 
integer  indicating  the  columnar  width  of  the  data  value  to  be 
dumped . 

NOTES:  (1)  If  elnarri^  = BN,  the  data  field  within  the  DF  will 

contain  the  name  of  the  data  block  being  dumped. 

(2)  Data  values  of  type  real  will  be  dumped  in 
either  floating  point  format  or  exponential 
format,  depending  upon  which  provides  the  greater 
accuracy . 

(3)  If  a data  element  of  type  pointer  consists  of  a 
cross-file  pointer  value,  the  SCOPE  or  CPFMS 
permanent  file  name  will  be  included  in  paren- 
theses in  the  DF  immediately  after  the  block 
name;  For  example,  BLOCKA  (PERMFILE,  ID=ABCD) 
for  a SCOPE  file;  and  BLOCKS  (DDG120,  DDG120) 
for  a CPFMS  file- 
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> ’ Vilrprc',  i.-'o  li'pcf' 

This  statement  must  be  used  when  array  data  elements  are 
to  be  dumped.  The  parameters  plyinrrir  and  lolnpe''  are  as  defined 
in  the  ,-;nlppee  statement  (see  previous  description). 

The  parameter  valapc^  is  either  a positive  integer,  indicating 
the  number  of  values  to  be  dumped  from  the  array,  or  an 
asterisk  (*)  immediately  followed  by  a positive  integer,  indi- 
cating the  columnar  width  of  the  field  in  the  data  that  is  to 
receive  the  number  of  values  that  will  be  dumped  for  the  array. 

t.  • jr  ‘ '•ol.'.pcc 

This  statement  must  be  used  when  textual  data  elements 
are  to  be  dumped.  The  parameter  t extp  Lninn  is  the  data 
element  name  as  it  appears  in  the  block-type  definition.  The 
parameter  c Z.ip.  ,'  is  either  a positive  integer,  indicating  the 
number  of  text  characters  to  be  dumped,  or  an  asterisk  (*) 

immediately  followed  by  a positive  integer.  This  integer 
indicates  the  columnar  width  of  the  field  in  the  data  that  is 
to  receive  the  number  of  text  characters  to  bo  dumped;  the 
text  string  will  be  dumped  immediately  following  this  field. 

rename  oca  spec 

This  statement  must  he  used  to  specify  the  number  of 
occurrences  that  are  to  be  dumped  from  a repeating  group;  the 
statement  must  precede  the  DD  statements  that  identify  those 
elements  which  will  be  processed  for  the  repeating  group  in  the 
current  data  base  dump.  The  parameter  rgname  is  the  repeating 
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qroup  name  as  it  appears  in  the  block-type  definition.  The 
parameter  cc*;?;  is  either  a positive  integer,  indicating  the 
number  of  occurrences  of  )\:na’vo  which  are  to  be  dumped  for  each 
block,  or  an  asterisk  {*)  immediately  followed  by  a positive 
integer,  denoting  the  columnar  width  of  the  field  in  the  data 
that  is  to  receive  the  number  of  occurrences  that  will  be 
dumped  from  the  repeating  group. 

f.  .k  Uri'.j 

The  K'JPFJ  statement  must  immediately  follow  the  set  of  DD 
statements  that  identify  those  elements  which  will  be  processed 
for  a repeating  group  in  the  current  execution  of  the  DUMP 
module.  For  each  rpna^e  occevea  statement  (see  previous  para- 
graph) of  a DD,  there  must  exist  an  ENDHG  statement. 

Additional  I n f o rmation  on  Data  Dumping 

When  the  value  for  a data  element  to  be  dumped  exceeds  its 
(jolcpen  specification  in  the  DD,  the  corresponding  field  in 
the  DF  will  be  filled  with  asterisks  (*'s).  When  the  number 
of  values  in  an  array  (or  the  number  of  repeating  group 
occurrences)  is  greater  than  its  valapei?  specification  in  the 
DD,  excess  values  in  the  array  (or  repeating  group  occurrences) 
will  not  be  dumped  but  an  appropriate  message  will  be  printed; 
if  t!  e number  is  less  than  the  valopea,  excess  fields  in  the 
DF  will  be  blank-filled  and  a message  will  be  printed. 

Finally,  when  no  value  has  been  loaded  for  an  element  that 

is  to  be  dumped,  the  corresponding  field  in  the  DF  will  be 
blank-filled  and  a message  will  be  printed. 
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Sample  Data  Definition  and  Data  FiJe 


The  relationship  between  the  values  to  be  dumped  to  the 
data  file  (DF)  and  the  data  definition  (DD)  is  best  shown  by 
way  of  an  example.  Hence,  a coordinated  sample  comprising 
a DD  and  a DF  ensues,  followed  by  a brief  discussion  of  the 
sample.  Assume  data  elements  in  the  DD  (i.e.,  STATE,  YEARA, 
etc.)  are  as  defined  in  the  block  type  STATES  which  was 
provided  in  the  earlier  discussion  of  the  LOAD  module. 


Sample  Data  Definition  (DD) 
TYPE  STATES 

PROCESS  ARIZONA, OHIO, VERMONT, RI 

STATE  10 

SKIP  5 

YEARA  4 

SKIP  5 

CAPITAL  10 

SKIP 

PRESPTR  *2,10 
SKIP 
AREA  7 
SKIP  3 
AREARANK  2 
SKIP  6 
POPUL  8 
SKIP  3 
POPRANK  2 
SKIP  6 
ELECVOTE  2 
SKIP 

CITIES  *2 
CITY  10 
SKIP  2 
CITYPOP  8 
SKIP 
ENDRG 
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Sai^l_e  _F  i Le  ) 


ARIZONA  1912  PHOENIX 

U 

13909.  6 1772482  33  6 

2PHOENIX  581562 

TUCSON  262933 

OHIO  1803  COLUMBUS 

7GARF1ELD  GRANT  HARDING  HARRISON  HAYES  MCKINLEY  TAFT 
41222.5  35  10652017  6 25 

9CLEVELAND  750879 

COLUMBUS  540025 
CINCINNATI  452524 
TOLEDO  383818 

AKRON  275425 

DAYTON  243601 

YOUNGSTOWN  139788 
CANTON  110053 

PARMA  100261 

VERMONT  1791  MONTPELIER 

ICOOLIDGE 

9609.38  43  444732  49  3 

0 

R.I.  1790  PROVIDENCE 

0 

1214.83  50  949723  29  4 

IPROVIDENCE  179116 


In  this  example,  values  of  four  data  blocks  (ARIZONA, 

OHIO,  VERMONT  and  RI ) of  the  block  type  STATES  have  been 
dumped  to  the  DF.  The  first  card  image  for  each  block 
contains  values  for  the  data  elements  STATE,  YEARA,  and 
CAPITAL  (e.g.,  Vermont,  1791,  Montpelier).  The  second  card 
image  contains  values  for  the  array  PRESPTR;  preceding  the 
values  is  a two-digit  field  containing  the  number  of  values 
in  PRESPTR  (e.g.,  OHIO  has  the  seven  values  Garfield,  Grant, 
Harding,  Harrison,  Hayes,  McKinley  and  Taft,  whereas  VERMONT 
has  only  the  value  Coolidge).  Since  neither  ARIZONA  nor  RI  have 
had  native-son  Presidents,  their  second  card  images  contains 
zero  in  columns  1-2. 
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he  third  card  image  of  each  block  contains  values  for 


the  elements  AREA,  AREARANK,  POPUL,  POPRANK  and  ELECVOTE. 
Values  on  the  fourth  card  image  and  those  that  follow  for 
the  repeating  group  CITIES  are  dumped,  one  occurrence  per 
card  image.  (In  effect,  each  card  image  contains  values 
for  the  elements  CITY  and  CITYPOP.)  Preceding  the  values 
for  the  first  occurrence  is  a two-digit  field  indicating 
the  number  of  occurrences  of  CITIES.  Thus,  for  the  block 
OHIO  there  are  nine  occurrences  of  CITIES  (designated  by 
the  integer  9 adjacent  to  Cleveland);  the  blocks  ARIZONA 
and  RI  have  two  and  one,  respectively.  The  fourth  card 
image  for  the  block  VERMONT,  which  has  no  CITIES  data, 
contains  zero  in  columns  1-2. 
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APPENDIX  A 


COMHADE  PERMANENT  P'lLE  MANAGEMENT  SYSTEM 

The  COMRADE  Permanent  File  Management  System  (CPFMS) 
affords  the  COMRADE  use r /prog r amme r a special  file  management 
capability  not  otherwise  available  under  the  SCOPE  permanent 
file  system.  Using  CPFMS,  the  user/programmer  is  able  to 
limit  file  access  to  those  persons  associated  with  a parti- 
I cular  design  project,  only.  This  control  is  achieved  by 

; creating  CPFMS  files  which  may  only  be  accessed  from  within 

a COMRADE  application  system. 

1 

i 

FILE-NAMING  CONVENTION 

Each  CPFMS  file  is  assigned  a unique  four-level  desig- 
nation. The  LI  (first-level)  name  COMR  is  given  to  all 
CPFMS  files.  The  L2  ( second- leve  1 ) name  is  that  of  the 
application  system  with  which  the  file  is  associated  (for 
example,  ISDS).  The  L3  (third-level)  name  is  that  of  a project 
within  the  application  system  with  which  the  file  is  associated 
(for  example,  DDG3).  The  L4  (fourth-level)  name  may  be  freely 
chosen;  it  is  used  to  suggest  the  contents  of  the  file  (WEIGHTS, 
for  example).  The  L2,  L3,  and  L4  names  are  concatenated, 
using  dashes,  to  form  a unique  permanent  file  name  which  can  be 
processed  by  the  SCOPE  permanent  file  system.  Each  level  name 
may  be  composed  of  as  many  as  eight  characters.  The  designation 
ISDS-DDG3-USERS  (with  ID=CPFM)  typifies  the  structure  of  a 
CPFMS  file  name. 
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FILE  ACCESS  CONTROL 


CPEMS  files  may  only  be  used  within  the  application 
system  fot  which  they  were  created;  thus  only  the  L3  and  L4 
names  actually  need  to  be  submitted  by  the  would-be  user. 

Two  schemes  foi  controlling  access  to  CPFMS  files  from 
within  application  systems  ate  pt ovided--the  pseudo-password, 
and  the  File-Access-Key/File-Access-Lock  (FAK/FAL).  Both 
ate  assigned  at  the  time  the  file  is  cataloged  within  the 
CPFMS  system.  If  the  pseudo-password  is  used,  access  to  that 
file  will  requite  that  the  user  submit  a pseudo-password  for 
a check.  If  the  password  submitted  by  the  user  is  identical 
to  the  one  assigned  at  the  time  the  file  was  cataloged,  access 
is  granted. 

If  the  FAK/FAL  is  used,  the  operation  is  mote  complex. 

The  FAL  assigned  to  a file  consists  ot  a 20-bit  field,  each 
bit  associated  with  a different  aspect  of  a project  effort 
(fot  example,  the  hull  design  portion).  The  FAK  assigned  to 
each  COMRADE  user  consists  of  60  bits,  organized  into  three 
20-bit  fields  called  sub-FAK's.  Each  of  the  three  sub-FAK's 
pertains  to  a different  level  of  file  access;  (1)  Attach 
with  read  permission  only;  (2)  attach  with  read-write  per- 
mission; or  (3)  attach  with  purge  permission.  Each  bit  of 
the  20-bit  sub-FAK  may  itself  be  associated  with  a particular 
subset  of  the  project  effort.  Those  sub-FAK  bit  positions 
that  correspond  to  the  subsets  that  the  user  is  allowed  to  use 
will  contain  I's.  Each  of  the  20-bit  sub-FAK's  will  be 
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APPENDIX  B 


DTNSRDC  CHARACTER  SET 


DISPLAY 

CHARACTER 

PUNCH 

PUNCH 

7-TRACK 

NOTE 

CODE 

026 

029 

TAPE 

NAME 

IF 

DIFF 

01 

AAA 

12-1 

61 

02 

BBB 

12-2 

62 

03 

CCC 

12-3 

63 

04 

DDD 

12-4 

64 

05 

EEE 

12-5 

65 

06 

FFF 

12-6 

66 

07 

GGG 

12-7 

67 

10 

HHH 

12-8 

70 

11 

III 

12-9 

71 

12 

JJJ 

11-1 

41 

13 

KKK 

11-2 

42 

14 

LLL 

11-3 

43 

15 

MMM 

11-4 

44 

16 

NNN 

11-5 

45 

17 

000 

11-6 

46 

20 

PPP 

11-7 

47 

21 

QQQ 

11-8 

50 

22 

RRR 

11-9 

51 

23 

SSS 

0-2 

22 

24 

TTT 

0-3 

23 

25 

UUU 

0-4 

24 

26 

VVV 

0-5 

25 

27 

WWW 

0-6 

26 

30 

XXX 

0-7 

27 

31 

YYY 

0-8 

30 

32 

ZZZ 

0-9 

31 

33 

000 

0 

12 

34 

111 

1 

01 

35 

222 

2 

02 

36 

333 

3 

03 

37 

444 

4 

04 

40 

555 

5 

05 

41 

666 

6 

06 

42 

111 

7 

07 

43 

888 

8 

10 

44 

999 

9 

11 

45 

++  + 

12 

12-8-6 

60 

PLUS 

46 

— 

11 

40 

MINUS 

47 

* * * 

11-8-4 

54 

ASTERISK 

50 

/// 

0-1 

21 

SLASH 

51 

( ( ( 

0-8-4 

12-8-5 

34 

LEFT  PAR 

52 

) ) ) 

12-8-4 

11-8-5 

74 

RT  PAR 

77 


H<5CU)1N0  PUiX  bUMUtt&T  TlUhkU 


TT 


DISPLAY 

CHARACTER 

PUNCH 

PUNCH 

7-TRACK 

NOTE 

CODE 

026 

029 

TAPE 

NAME 

IF 

DIFF 

53 

$$$ 

11-8-3 

53 

DOLLAR 

54 

= 'T  = 

8-3 

8-6 

13 

EQUAL 

55 

20 

BLANK 

56 

^ f f 

0-8-3 

33 

COMMA 

57 

• • • 

12-8-3 

73 

PERIOD 

60 

### 

0-8-6 

8-3 

36 

POUND 

61 

1 1 1 

8-7 

12-8-2 

17 

L BRACKET 

62 

1 1 1 

0-8-2 

11-8-2 

32 

R BRACKET 

63 

: : : 

8-2 

COLON 

64 

II  It  II 

8-4 

8-7 

14 

QUOTE 

65 

0-8-5 

35 

UNDERLINE 

66 

1 1 1 

11-8-2 

12-8-7 

52 

EXCLAMATION 

66 

! 1 ! 

11-0 

52 

EXCLAMATION 

67 

&&& 

0-8-7 

12 

37 

AMPERSAND 

70 

f t 1 

11-8-5 

8-5 

55 

APOSTROPHE 

71 

111 

11-8-6 

0-8-7 

56 

QUESTION 

72 

12-8-2 

12-8-4 

72 

LESS  THAN 

72 

«< 

12-0 

72 

LESS  THAN 

73 

>>> 

11-8-7 

0-8-6 

57 

GREATER 

74 

@@@ 

8-5 

8-4 

15 

AT 

75 

\\v 

12-8-5 

0-6-2 

75 

REVERSE  SLANT 

76 

AAA 

12-8-6 

11-8-7 

76 

CIRCUMFLEX 

77 

? r f 

12-8-7 

1 1-8-6 

77 

SEMICOLON 

55 

8-6 

0-8-4 

BLANK 
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APPENDIX  C 


SAMPLE  TERMINAL  SESSION  USING  CDMS 

DIALOGUE  AT  THE  TERMINAL 

(The  numbers  in  parentheses  at  the  right  have  been 
provided  to  facilitate  the  discussion  that  follows). 


NSRDC  6700  INTERCOM  V4 . 4 
DATE  06/04/76 
TIME  12.23.10. 

LOGIN, CXXXYYYZZZ, 1234 567890, SUP  ( 1) 

COMMAND-  COMRADE,  CDMS  (2) 

COMRADE  TIME:  12.24.16. 

DATE:  06/04/76 

REQUEST-  DEFINE  ( 3 ) 

REQUEST-  ATTACH,BTDATA,FRESIDENTSBLOCKTYPE,ID=CABG.  (4) 

REQUEST-  DATABASE, NEWDB  (5) 

REQUEST-  CREATE  PRES/BTDATA  (6) 

REQUEST-  PRINT  PRES  (7) 


BLOCK  TYPE-PRES 
SUB-BLOCK  1-PERSONAL 


ELEMENT 

1- 

SURNAME 

ALPHA 

INVERTED 

ELEMENT 

2- 

FIRSTNAM 

ALPHA 

ELEMENT 

3- 

INITIAL 

ALPHA 

ELEMENT 

4- 

STATEB 

ALPHA 

INVERTED 

ELEMENT 

5- 

YEARS 

INTEGER 

INVERTED 

ELEMENT 

6- 

MONTHS 

ALPHA 

ELEMENT 

7- 

DAYS 

INTEGER 

ELEMENT 

8- 

PARTY 

ALPHA 

INVERTED 

ELEMENT 

9- 

RELIGION 

ALPHA 

INVERTED 

ELEMENT 

10- 

ANCESTRY 

ALPHA 

ELEMENT 

11- 

COLLEGE 

ALPHA 
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SUB-BLOCK  2-  FAMILY 


ELEMENT 

1- 

WIPE 

ALPHA 

ELEMENT 

2- 

YEARM 

INTEGER 

ELEMENT 

3- 

CHILDREN 

INTEGER 

REPEATING  GROUP  1-  MARRIAGE 

ELEMENT  1 
ELEMENT  2 
ELEMENT  3 


REQUEST- 

CATALOG, NEWDB, USPRESDATABASE, ID=CABG,AC=1234 . 

(8) 

REQUEST- 

LOAD 

(9) 

REQUEST- 

EDITOR 

(10) 

TYPE  "EDITOR"  UPON  ENTERING  COMMAND  MODE.  AFTER  SAVING 
FILE(S)  AND  LEAVING  EDITOR,  TYPE  "CDMS"  TO  RETURN  TO 
THIS  MODULE. 


COMMAND-  EDITOR  (11) 

. .C  S 

ENTER  LINES 
TYPE  PRES 
RECORD  80 
PROCESS  ALL 
BN  8 
SKIP  2 
SURNAME  10 
SKIP  2 
FIRSTNAM  10 
SKIP  2 
INITIAL  1 
SKIP  2 
STATES  10 
SKIP 
YEARS  4 
SKIP  2 
MONTHS  10 
SKIP  2 

DAYS  2 * 

SKIP  2 
PARTY  10 
SKIP  2 
RELIGION  10 
SKIP  2 
ANCESTRY  10 
SKIP  2 
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COLLEGE  10 
SKIP 

MARRIAGE  *1 
WIFE  10 
SKIP  2 
YEARM  4 
SKIP  2 
CHILDREN  2 
SKIP 
ENDRG 

. .S  PRESLID  N 

. .B 


COMMAND-  CDMS  (12) 

REQUEST-  ATTACH,DATFILE,PRESIDENTSDATA,ID=CARG.  (13) 

REQUEST-  USE  PRESL 1 D , DATE  1 LE  (14) 

37  DATA  BLOCKS  CREATED 
LOAD  COMPLETE 

REQUEST-  FILES  (15) 

‘BTDATA  *NEWDB  PRESLID  ‘DATFILE 

REQUEST-  UNLOAD, BTDATA, PRESLID, DATFILE.  (16) 

REQUEST-  QUERY  (17) 

REQUEST-  FOR  PARTY  .EQ.  "REPUBLICAN"  (18) 

REQUEST-  HITS  (19) 

THERE  ARE  17  HITS  ON  HITFILE 

REQUEST-  PRINT  SURNAME  (20) 


SURNAME  LINCOLN 

SURNAME  JOHNSON 

SURNAME  GRANT 

SURNAME  HAYES 

SURNAME  GARFIELD 

SURNAME  ARTHUR 

SURNAME  HARRISON 

SURNAME  MCKINLEY 

SURNAME  ROOSEVELT 

SURNAME  TAFT 

SURNAME  WILSON 

SURNAME  HARDING 

SURNAME  COOLIDGE 
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SURNAME  HOOVER 

SURNAME  EISENHOWER 

SURNAME  NIXON 

SURNAME  FORD 


REQUEST-  QUALIFY 

REQUEST-  PRINT  IN 
RELIGION 

SURNAME 

STATEB  .EQ.  "OH 

COLS  SURNAME, 

FIRSTNAM 

10" 

FIRSTNAM, 

YEARB 

YEARB, 

RELIGION 

(21) 

(22) 

GARFIELD 

JAMES 

1831 

DIS. CHRIST 

GRANT 

ULYSSES 

1822 

METHODIST 

HARDING 

WARREN 

1865 

BAPTIST 

HARRISON 

BENJAMIN 

1833 

PRESBYT. 

HAYES 

RUTHEFORD 

1843 

METHODIST 

MCKINLEY 

WILLIAM 

1843 

METHODIST 

TAFT 

WI LLIAM 

1857 

UNITARIAN 

REQUEST-  UPDATE 

( 23) 

REQUEST-  MODIFY  L 

I NCOLN , WI LSON /PARTY/ * 

(24) 

DATA  HLOCK  = LINCOLN 
PARTY  REPUBLICAN 

ENTER  VALUE-  $S  (25) 

DATA  BLOCK  = aILSON 
PARTY  REPUBLICAN 

ENTER  VALUE-  DEMOCRATIC  (26) 

REQUEST-  PRINT  WILSON  (27) 

DATA  BLOCK 

SURNAME 
FIRSTNAM 
INITIAL 
STATED 
YEARB 
MONTHB 
DAYB 
PARTY 
RELIGION 
ANCESTRY 
COLLEGE 


= WILSON 

WILSON 

WOODROW 

VIRGINIA 

1856 

DECEMBER 

28 

DEMOCRATIC 

PRESBYT. 

ENGLISH 

PRINCETON 
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***  REPEATING  GROUP  MARRIAGE  ** 

WIFE  ELLEN 

YEARM 

CHILDREN  J 

WIFE  EDITH 

YEARM  1914 

CHILDREN  0 

***  END  REPEATING  GROUP  *** 

REQUEST-  OUTPUT, FILE 

REQUEST-  PRINT  ALL 

THERE  ARE  37  DATA  BLOCKS  TO 
SHALL  WE  CONTINUE?-  YES 

REQUEST-  SEND, 6700 

REQUEST-  EXIT 

????  LOGOUT 

CPA  S4.93^ 

CPB  .000  St.r 

SS  SS.970  SEC 

EST.  SYSTEM  ■ OST  S H.H2 
EST.  CONNECT  > OST  $ 9.? 7 

CONNECT  TIME  0 HRS.  -4  MIN 

06/ 04 '76  LOGGED  OUT  AT  li.I7. 


OCC-1 

OCC-2 

I 28) 
( 29) 

BE  PROCESSED. 

< 30) 
( 31  ) 
( )2) 
( 3 3 I 


DISCUSSION 

The  user  "loqs  in"  to  INTERCOM  (1)  jnd  enters  the  CDMS 
prucedaie  (2).  He  wishes  to  create  a data  base  cuntaininq 
information  pertaining  to  the  United  States  Presidents.  First, 
he  enters  the  DEFINE  module  (3)  for  the  purpose  of  creating  a 
bloc)r  type.  The  input  to  the  DEFINE  module,  i.e.,  the  block 
type  definition,  has  been  stored  previously  on  a SCOPE 
permanent  file  which  the  user  now  attaches  (4).  He  indicates 
that  the  local  file  name  of  the  active  data  base  (in  this 
case,  the  data  base  he  is  about  to  create)  is  NEWDB  (5),  and 
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he  initiates  the  block  type  definition  (6).  The  newly-defined 
block  type,  PRES,  is  printed  (7)  and  the  new  data  base,  NEWDB, 

IS  made  permanent  (8). 

To  load  data  blocks  onto  the  data  base,  the  user  must 
leave  the  DEEINK  module  and  enter  the  LOAD  module  (9).  Data 
Items  to  be  loaded  onto  the  data  base  exist,  although  the 
detinition  of  this  data,  the  DD,  does  not.  The  user  wishes 
t ) creat*-  this  DD  using  EDITOR  (10).  He  enters  the  EDITOR 
ptojfjiT  11  , I'lejtes  and  saves  a file  (the  DD),  and  reenters 
t tif  I,  lAl  Tioifal"  (iJi.  The  actual  information  describing  the 
.o.  pfe-  i f»-n^  exists  on  a permanent  file  which  the  user 
it  t ii.  It,  I no  t tie  loatl  IS  initiated  by  the  USE  command  (14). 

After  the  data  t,a.se  has  fieer  successfully  loaded,  the 
• r litermine.  the  name*?  of  those  local  files  that  are  still 
I • I ve  I in.)  then  lispose;;  of  those  he  no  longer  needs  (lb). 

He  now  ent.r-,  the  iJUERy  module  (17).  His  first  query  (18) 
prorluces  17  "hits"  (!<*),  indicating  that  there  have  been  17 
Republican  presidents.  He  prints  the  SURNAME  of  these  presi- 
.p-nt  s (2U).  Wistiing  to  Know  mort*  about  the  Republican  presi- 
d**nts  wtio  were  tiorn  in  Ofiio,  fie  enters  a OUALIEY  command  (21) 
and  receives  a report  on  the  seven  G.O.P.  Buckeye  presidents, 
the  information  printed  in  columns  (22). 

Noting  that  some  of  the  information  regarding  PARTY  seems 
to  be  in  error,  the  user  switches  to  the  UPDATE  module  (23). 
Specifically,  he  intends  to  modify  the  PARTY  of  those  data 
blocks  named  LINCOLN  and  WILSON  (24).  Remembering  at  the 
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last  moment,  however,  that  Lincoln  was  indeed  a Republican, 
the  user  cancels  this  part  of  the  Update  request  (25)  and 
proceeds  to  correct  PARTY  WILSON  (26).  He  now  requests 
that  the  entire  contents  of  the  data  block  WILSON  be 
printed  (21) . 

Finally,  the  user,  wishing  to  have  a complete  printout 
of  his  data  base  contents,  switches  to  the  off-line  mode 
(which  will  result  in  his  output  information  being  written 
to  the  Report  File  rather  than  to  the  user's  terminal)  (28), 
and  then  issues  the  request  to  print  all  data  blocks  (29). 
After  the  request  has  been  affirmed  (30),  the  data  blocks 
are  written  to  the  Report  File  which  is  then  routed  to 
Building  17,  DTNSRDC  to  be  printed  with  a high-speed  printer 
( 31)  . 

His  work  completed  for  now,  the  user  leaves  CDMS  (32) 
and  "logs  out"  of  INTERCOM  (33). 
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APPENDIX  D 


SUMMARY  OF  CDMS  STORAGE  CAPACITIES 

MAXIMUM  DATA  BLOCK  STORAGE  CAPACITIES: 

Number  of  data  blocks  on  each  file 2**53-l 

Number  of  words  in  each  data  block 262,143 

Number  of  blocks  that  may  be  saved  at  any  one  time 

for  reallocation 81,090 

Number  of  full  or  partial  data  blocks  that  may  be 


contained  in  buffer  at  any  one  time 20 

MAXIMUM  INVERTED  LIST  STORAGE  CAPACITIES: 

Number  of  inverted  element  lists  per  file 100 

Number  of  entries  pet  inverted  list  element 173,740 

Number  of  qualifying  inverted  list  entries 

per  query 64,897 


MAXIMUM  BLOCK  TYPE  STORAGE  CAPACTIES: 

Number  of  block  types  on  each  file 100 

Number  of  data  elements  per  block  type 250 

Number  of  subblocks  per  block  type 8 

Number  of  repeating  groups  per  subblock 14 

Number  of  elements  per  repeating  group 50 


fRsciojiNo  Pack  blamunot 


37 


2 


I 


APPENDIX  E 

USE  OF  CDMS  IN  BATCH  ENVIRONMENT 

The  COMRADE  Executive  was  originally  designed  and  imple- 
mented as  an  interactive  system.  There  arose,  however,  a need 
to  be  able  to  perform  large  non-interactive  jobs  while  operating 
under  COMRADE.  Thus  a batch  capability  was  added  to  the 
Executive . 

The  incorporation  of  a batch  mode  capability  forced 
several  significant  changes  in  the  format  of  user  input,  data 
and  output  results,  the  major  one  being  the  grouping  of  input 
data  as  logical  card  records,  one  logical  record  for  each 
executed  program  that  requires  data.  One  record  (the  first 
record)  to  indicate  names  of  the  procedures  to  be  executed  by 
the  Executive  must  always  be  included  as  well  as  any  input 
required  by  the  PDL  programs.  In  the  case  of  CDMS,  one  addi- 
tional data  record,  that  required  by  the  CDMS  program,  must  be 
included . 

The  input  to  CDMS  consists  of  a series  of  cards  containing 
the  CDMS  commands  to  be  performed.  Commands  in  batch  have  the 
same  syntax  as  those  issued  interactively,  the  only  difference 
being  that,  under  the  interactive  mode,  the  user  may  be 
consulted  about  continuing  processing  or  file  disposition. 

CDMS,  in  batch  mode,  assumes  the  user  knows  what  he  wants, 
and  attempts  to  respond  fully  to  each  command. 
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A sample  run  follows: 


job  card  (must  have  at  least  CM  61000) 

charge  card 

COMRADE. 

7/8/9 

CDMS 

SIGNOFF 

7/8/9 

ATTACH , CDMSDB , PRESIDENTSDATABASE , ID=COMR . 

DATABASE, CDMSDB 

STATS 

HELP 

BTNAMES 

DEFINE 

PRINT  PRES 

EXIT 

6/7/8/9 
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